You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Nick Pratt <nb...@gmail.com> on 2012/11/28 21:00:34 UTC
Dynamic Components
Martin
The approach of adding the Sub/Details Panel to a DummyPage works fine for
basic Panels, but there are a few problems I've hit:
1. onInitialize() isnt called - Im assuming this is because the Panel
doesnt go through a normal lifecycle before being rendered back to the ART?
2. None of the Ajax/Links work - they are loading up the DummyPage
Now Im assuming this is all because the Component/Panel on the server side
isnt associated with a real live page?
Following on from a discussion thread that Chris Colman was going on about
IComponentResolvers and those components being second class citizens, would
it be possible to create dynamic components in a Page, and store them in a
non-markup related area of the Page, such that they would go through normal
lifecycle events etc, and AJAX callbacks would work to the Page, but they
wouldnt be associated with the normal markup/component hierarchy?
Based on Chris' comments, it seems like he has the initial stages of a
workable solution to breaking the Component / Markup hierarchy and allowing
a very flexible way of building applications. While I dont know what else
Component Queueing was going to add, it seems that such functionality would
provide a way to break the current hierarchy matching requirement.
In my specific case, Im ok if the Components get thrown away on a full page
(re)render, or that if Components were instantiated and not referenced in
the markup, then they could be thrown away.
While this might not suit the core framework for v7.0, could I build such
functionality using the existing v6 APIs (maybe via a custom BasePage/
Component wrapper) and hooking in to the rendering cycle?
N
RE: Dynamic Components
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
I found a problem with the previous algorithm and fixed it. The problem
involved Panel markup that contained some markup with wicket:id tags
*outside* the
<wicket:panel>
</wicket:panel>
element. These were resulting in components being added also but they
shouldn't. I now add an extra check with a 'processing' semaphore that,
when > 0, indicates that wicket:id tags should be processed, otherwise
they are ignored.
boolean isPanel = container instanceof Panel;
// Panels should not process markup elements outside the
// <wicket:panel> element but pages should process all markup
int processing = isPanel ? 0 : 1;
for (MarkupElement markupElement: markupElements)
{
if ( markupElement instanceof WicketTag )
{
WicketTag wicketTag = (WicketTag)markupElement;
if ( wicketTag.isPanelTag())
{
if ( wicketTag.getXmlTag().isOpen() )
processing++;
else
processing--;
}
}
else if
(
processing > 0
&&
markupElement instanceof ComponentTag )
{
ComponentTag tag = (ComponentTag)markupElement;
String rawTagId = tag.getId();
if ( rawTagId != null )
{
String tagId;
...
>-----Original Message-----
>From: Nick Pratt [mailto:nbpratt@gmail.com]
>Sent: Thursday, 29 November 2012 7:01 AM
>To: users@wicket.apache.org
>Subject: Dynamic Components
>
>Martin
>
>The approach of adding the Sub/Details Panel to a DummyPage works fine
for
>basic Panels, but there are a few problems I've hit:
>1. onInitialize() isnt called - Im assuming this is because the Panel
>doesnt go through a normal lifecycle before being rendered back to the
ART?
>2. None of the Ajax/Links work - they are loading up the DummyPage
>
>Now Im assuming this is all because the Component/Panel on the server
side
>isnt associated with a real live page?
>
>Following on from a discussion thread that Chris Colman was going on
about
>IComponentResolvers and those components being second class citizens,
would
>it be possible to create dynamic components in a Page, and store them
in a
>non-markup related area of the Page, such that they would go through
normal
>lifecycle events etc, and AJAX callbacks would work to the Page, but
they
>wouldnt be associated with the normal markup/component hierarchy?
>
>Based on Chris' comments, it seems like he has the initial stages of a
>workable solution to breaking the Component / Markup hierarchy and
allowing
>a very flexible way of building applications. While I dont know what
else
>Component Queueing was going to add, it seems that such functionality
would
>provide a way to break the current hierarchy matching requirement.
>
>In my specific case, Im ok if the Components get thrown away on a full
page
>(re)render, or that if Components were instantiated and not referenced
in
>the markup, then they could be thrown away.
>
>While this might not suit the core framework for v7.0, could I build
such
>functionality using the existing v6 APIs (maybe via a custom BasePage/
>Component wrapper) and hooking in to the rendering cycle?
>
>N
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Dynamic Components
Posted by Bas Gooren <ba...@iswd.nl>.
Sure. After my original post we simplified the code a bit. This is the
latest version we use in production.
http://pastebin.com/WnxNVj2n
This time I've set the paste to "never expire".
Met vriendelijke groet,
Kind regards,
Bas Gooren
Op 12-2-2013 20:57, schreef Decebal Suiu:
> Hi
>
> Can I see the code. The pastebin show me a "Unknown Paste ID!" message on
> link [1].
>
> [1] http://pastebin.com/p4cSNsUw
>
> Best regards,
> Decebal
>
>
>
> --
> View this message in context: http://apache-wicket.1842946.n4.nabble.com/Dynamic-Components-tp4654308p4656289.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
Re: Dynamic Components
Posted by Decebal Suiu <de...@asf.ro>.
Hi
Can I see the code. The pastebin show me a "Unknown Paste ID!" message on
link [1].
[1] http://pastebin.com/p4cSNsUw
Best regards,
Decebal
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Dynamic-Components-tp4654308p4656289.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Dynamic Components
Posted by Nick Pratt <nb...@gmail.com>.
This works great! Many thanks.
I made a small addition to allow the markupId to be passed in via a new
constructor - this is for the case where a JS component/lib creates new
elements and inserts them into a specific place in the DOM - I pass the new
ID back via an Ajax call, and then let the helper deal with hooking up the
Wicket component.
Thanks again
Nick
On Wed, Nov 28, 2012 at 5:34 PM, Bas Gooren <ba...@iswd.nl> wrote:
> Hi,
>
> We've written the following class to dynamically add components to a page
> and then render them in an ajax request:
>
> http://pastebin.com/p4cSNsUw
>
> The rendered component is in the current page, not in a dummy page, so
> everything works as expected.
> The only thing that doesn't work is a full re-render, since that requires
> a "hook" in the page markup, which does not exist (hence "dynamic
> components"). To circumvent that, the dynamic components are automatically
> removed on a full page re-render.
>
> Have a look at the code, maybe it helps you. It's rather simple when you
> think about it.
> onInitialize() and ajax calls in the dynamically injected components work
> as expected for us.
>
> We use it in our (wicket 1.5) cms to dynamically inject editors and popups.
>
> Met vriendelijke groet,
> Kind regards,
>
> Bas Gooren
>
> Op 28-11-2012 21:00, schreef Nick Pratt:
>
>> Martin
>>
>> The approach of adding the Sub/Details Panel to a DummyPage works fine for
>> basic Panels, but there are a few problems I've hit:
>> 1. onInitialize() isnt called - Im assuming this is because the Panel
>> doesnt go through a normal lifecycle before being rendered back to the
>> ART?
>> 2. None of the Ajax/Links work - they are loading up the DummyPage
>>
>> Now Im assuming this is all because the Component/Panel on the server side
>> isnt associated with a real live page?
>>
>> Following on from a discussion thread that Chris Colman was going on about
>> IComponentResolvers and those components being second class citizens,
>> would
>> it be possible to create dynamic components in a Page, and store them in a
>> non-markup related area of the Page, such that they would go through
>> normal
>> lifecycle events etc, and AJAX callbacks would work to the Page, but they
>> wouldnt be associated with the normal markup/component hierarchy?
>>
>> Based on Chris' comments, it seems like he has the initial stages of a
>> workable solution to breaking the Component / Markup hierarchy and
>> allowing
>> a very flexible way of building applications. While I dont know what else
>> Component Queueing was going to add, it seems that such functionality
>> would
>> provide a way to break the current hierarchy matching requirement.
>>
>> In my specific case, Im ok if the Components get thrown away on a full
>> page
>> (re)render, or that if Components were instantiated and not referenced in
>> the markup, then they could be thrown away.
>>
>> While this might not suit the core framework for v7.0, could I build such
>> functionality using the existing v6 APIs (maybe via a custom BasePage/
>> Component wrapper) and hooking in to the rendering cycle?
>>
>> N
>>
>>
>
Re: Dynamic Components
Posted by Bas Gooren <ba...@iswd.nl>.
Hi,
We've written the following class to dynamically add components to a
page and then render them in an ajax request:
http://pastebin.com/p4cSNsUw
The rendered component is in the current page, not in a dummy page, so
everything works as expected.
The only thing that doesn't work is a full re-render, since that
requires a "hook" in the page markup, which does not exist (hence
"dynamic components"). To circumvent that, the dynamic components are
automatically removed on a full page re-render.
Have a look at the code, maybe it helps you. It's rather simple when you
think about it.
onInitialize() and ajax calls in the dynamically injected components
work as expected for us.
We use it in our (wicket 1.5) cms to dynamically inject editors and popups.
Met vriendelijke groet,
Kind regards,
Bas Gooren
Op 28-11-2012 21:00, schreef Nick Pratt:
> Martin
>
> The approach of adding the Sub/Details Panel to a DummyPage works fine for
> basic Panels, but there are a few problems I've hit:
> 1. onInitialize() isnt called - Im assuming this is because the Panel
> doesnt go through a normal lifecycle before being rendered back to the ART?
> 2. None of the Ajax/Links work - they are loading up the DummyPage
>
> Now Im assuming this is all because the Component/Panel on the server side
> isnt associated with a real live page?
>
> Following on from a discussion thread that Chris Colman was going on about
> IComponentResolvers and those components being second class citizens, would
> it be possible to create dynamic components in a Page, and store them in a
> non-markup related area of the Page, such that they would go through normal
> lifecycle events etc, and AJAX callbacks would work to the Page, but they
> wouldnt be associated with the normal markup/component hierarchy?
>
> Based on Chris' comments, it seems like he has the initial stages of a
> workable solution to breaking the Component / Markup hierarchy and allowing
> a very flexible way of building applications. While I dont know what else
> Component Queueing was going to add, it seems that such functionality would
> provide a way to break the current hierarchy matching requirement.
>
> In my specific case, Im ok if the Components get thrown away on a full page
> (re)render, or that if Components were instantiated and not referenced in
> the markup, then they could be thrown away.
>
> While this might not suit the core framework for v7.0, could I build such
> functionality using the existing v6 APIs (maybe via a custom BasePage/
> Component wrapper) and hooking in to the rendering cycle?
>
> N
>
RE: Dynamic Components
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
>> >Martin
>> >
>> >The approach of adding the Sub/Details Panel to a DummyPage works
fine
>> for
>> >basic Panels, but there are a few problems I've hit:
>> >1. onInitialize() isnt called - Im assuming this is because the
Panel
>> >doesnt go through a normal lifecycle before being rendered back to
the
>> ART?
>> >2. None of the Ajax/Links work - they are loading up the DummyPage
>>
>> The method I've provided involves calling a static
>> addDynamicComponents(this); method from the onInitialise of a base
class
>> Panel and base class Page. Obviously all pages and panels need to
derive
>> from these common, application defined, Page and Panel classes - but
>> that's no problem and most Wicket apps probably already do this as
it's
>> an easy way to add styling, behaviour etc., across the entire app
>> easily.
>>
>
>You can
>use org.apache.wicket.Application#getComponentInitializationListeners
to do
>the same.
>For example check that the component is a Page/Panel and has package
name
>that is in your namespace.
Thanks Martin, I wasn't aware of that particular listener mechanism.
>
>
>>
>> This mechanism results in the dynamic components being added within
the
>> onInitialize method and so the dynamic components' own onInitialize
>> methods are called which means you can have nested addition of
dynamic
>> components to any level your require.
>>
>> Because the components are added within the onInitialize method of
their
>> parent component all the AJAX goodies work as expected :)
>>
>>
>> >
>> >Now Im assuming this is all because the Component/Panel on the
server
>> side
>> >isnt associated with a real live page?
>> >
>> >Following on from a discussion thread that Chris Colman was going on
>> about
>> >IComponentResolvers and those components being second class
citizens,
>> would
>> >it be possible to create dynamic components in a Page, and store
them
>> in a
>> >non-markup related area of the Page, such that they would go through
>> normal
>> >lifecycle events etc, and AJAX callbacks would work to the Page, but
>> they
>> >wouldnt be associated with the normal markup/component hierarchy?
>> >
>> >Based on Chris' comments, it seems like he has the initial stages of
a
>> >workable solution to breaking the Component / Markup hierarchy and
>> allowing
>> >a very flexible way of building applications. While I dont know
what
>> else
>> >Component Queueing was going to add, it seems that such
functionality
>> would
>> >provide a way to break the current hierarchy matching requirement.
>> >
>> >In my specific case, Im ok if the Components get thrown away on a
full
>> page
>> >(re)render, or that if Components were instantiated and not
referenced
>> in
>> >the markup, then they could be thrown away.
>> >
>> >While this might not suit the core framework for v7.0, could I build
>> such
>> >functionality using the existing v6 APIs (maybe via a custom
BasePage/
>> >Component wrapper) and hooking in to the rendering cycle?
>> >
>> >N
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
>--
>Martin Grigorov
>jWeekend
>Training, Consulting, Development
>http://jWeekend.com <http://jweekend.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Dynamic Components
Posted by Martin Grigorov <mg...@apache.org>.
On Thu, Nov 29, 2012 at 7:00 AM, Chris Colman
<ch...@stepaheadsoftware.com>wrote:
> >Martin
> >
> >The approach of adding the Sub/Details Panel to a DummyPage works fine
> for
> >basic Panels, but there are a few problems I've hit:
> >1. onInitialize() isnt called - Im assuming this is because the Panel
> >doesnt go through a normal lifecycle before being rendered back to the
> ART?
> >2. None of the Ajax/Links work - they are loading up the DummyPage
>
> The method I've provided involves calling a static
> addDynamicComponents(this); method from the onInitialise of a base class
> Panel and base class Page. Obviously all pages and panels need to derive
> from these common, application defined, Page and Panel classes - but
> that's no problem and most Wicket apps probably already do this as it's
> an easy way to add styling, behaviour etc., across the entire app
> easily.
>
You can
use org.apache.wicket.Application#getComponentInitializationListeners to do
the same.
For example check that the component is a Page/Panel and has package name
that is in your namespace.
>
> This mechanism results in the dynamic components being added within the
> onInitialize method and so the dynamic components' own onInitialize
> methods are called which means you can have nested addition of dynamic
> components to any level your require.
>
> Because the components are added within the onInitialize method of their
> parent component all the AJAX goodies work as expected :)
>
>
> >
> >Now Im assuming this is all because the Component/Panel on the server
> side
> >isnt associated with a real live page?
> >
> >Following on from a discussion thread that Chris Colman was going on
> about
> >IComponentResolvers and those components being second class citizens,
> would
> >it be possible to create dynamic components in a Page, and store them
> in a
> >non-markup related area of the Page, such that they would go through
> normal
> >lifecycle events etc, and AJAX callbacks would work to the Page, but
> they
> >wouldnt be associated with the normal markup/component hierarchy?
> >
> >Based on Chris' comments, it seems like he has the initial stages of a
> >workable solution to breaking the Component / Markup hierarchy and
> allowing
> >a very flexible way of building applications. While I dont know what
> else
> >Component Queueing was going to add, it seems that such functionality
> would
> >provide a way to break the current hierarchy matching requirement.
> >
> >In my specific case, Im ok if the Components get thrown away on a full
> page
> >(re)render, or that if Components were instantiated and not referenced
> in
> >the markup, then they could be thrown away.
> >
> >While this might not suit the core framework for v7.0, could I build
> such
> >functionality using the existing v6 APIs (maybe via a custom BasePage/
> >Component wrapper) and hooking in to the rendering cycle?
> >
> >N
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com <http://jweekend.com/>
RE: Dynamic Components
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
>Martin
>
>The approach of adding the Sub/Details Panel to a DummyPage works fine
for
>basic Panels, but there are a few problems I've hit:
>1. onInitialize() isnt called - Im assuming this is because the Panel
>doesnt go through a normal lifecycle before being rendered back to the
ART?
>2. None of the Ajax/Links work - they are loading up the DummyPage
The method I've provided involves calling a static
addDynamicComponents(this); method from the onInitialise of a base class
Panel and base class Page. Obviously all pages and panels need to derive
from these common, application defined, Page and Panel classes - but
that's no problem and most Wicket apps probably already do this as it's
an easy way to add styling, behaviour etc., across the entire app
easily.
This mechanism results in the dynamic components being added within the
onInitialize method and so the dynamic components' own onInitialize
methods are called which means you can have nested addition of dynamic
components to any level your require.
Because the components are added within the onInitialize method of their
parent component all the AJAX goodies work as expected :)
>
>Now Im assuming this is all because the Component/Panel on the server
side
>isnt associated with a real live page?
>
>Following on from a discussion thread that Chris Colman was going on
about
>IComponentResolvers and those components being second class citizens,
would
>it be possible to create dynamic components in a Page, and store them
in a
>non-markup related area of the Page, such that they would go through
normal
>lifecycle events etc, and AJAX callbacks would work to the Page, but
they
>wouldnt be associated with the normal markup/component hierarchy?
>
>Based on Chris' comments, it seems like he has the initial stages of a
>workable solution to breaking the Component / Markup hierarchy and
allowing
>a very flexible way of building applications. While I dont know what
else
>Component Queueing was going to add, it seems that such functionality
would
>provide a way to break the current hierarchy matching requirement.
>
>In my specific case, Im ok if the Components get thrown away on a full
page
>(re)render, or that if Components were instantiated and not referenced
in
>the markup, then they could be thrown away.
>
>While this might not suit the core framework for v7.0, could I build
such
>functionality using the existing v6 APIs (maybe via a custom BasePage/
>Component wrapper) and hooking in to the rendering cycle?
>
>N
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org