Re: Dynamic Components
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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Dynamic Components
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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: 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 >> >> 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-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > >-- >Martin Grigorov >jWeekend >Training, Consulting, Development >http://jWeekend.com <http://jweekend.com/> - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Dynamic Components
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 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
On Thu, Nov 29, 2012 at 7:00 AM, Chris Colman 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-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com <http://jweekend.com/>
RE: 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 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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Dynamic Components
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
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
// 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:nbpr...@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Dynamic Components
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
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
Hi, thanks for ur help, folks... I'm currently looking at the WicketWebBeans project. Seems promising on this issue. On Sun, Nov 8, 2009 at 4:35 AM, Igor Vaynberg wrote: > this should give you a very decent starting point > > > https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/attic/wicketstuff-crud/ > > -igor > > On Sat, Nov 7, 2009 at 5:38 AM, Gw wrote: > > Hi people, > > > > Does anyone know how to dynamically add components to a form? > > The types and numbers of the components are arbitrary, and will be > > determined programmatically. > > In one page, the form may contain 1 textbox, 2 buttons. In another page, > it > > may contain 2 textareas, 1 checkbox, and so on... > > > > Perhaps there's a framework over Wicket for this? > > Lots of thanks in advance for ur assist. > > > > Regards, > > Mike > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
RE: dynamic components
Create a panel with dummy components (e.g. Label components where the label is an empty string). Later you can "replace" one or more of the components. One complication is that some wicket components (e.g. Image) need to be attached to specialized HTML. However, the basic principle still stands. -Original Message- From: Gw [mailto:not4spamm...@gmail.com] Sent: Saturday, November 07, 2009 7:38 AM To: users@wicket.apache.org Subject: dynamic components Hi people, Does anyone know how to dynamically add components to a form? The types and numbers of the components are arbitrary, and will be determined programmatically. In one page, the form may contain 1 textbox, 2 buttons. In another page, it may contain 2 textareas, 1 checkbox, and so on... Perhaps there's a framework over Wicket for this? Lots of thanks in advance for ur assist. Regards, Mike - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: dynamic components
this should give you a very decent starting point https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/attic/wicketstuff-crud/ -igor On Sat, Nov 7, 2009 at 5:38 AM, Gw wrote: > Hi people, > > Does anyone know how to dynamically add components to a form? > The types and numbers of the components are arbitrary, and will be > determined programmatically. > In one page, the form may contain 1 textbox, 2 buttons. In another page, it > may contain 2 textareas, 1 checkbox, and so on... > > Perhaps there's a framework over Wicket for this? > Lots of thanks in advance for ur assist. > > Regards, > Mike > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: dynamic components
Can build using repeaters, or an form with all possible form components added on it, with they isVisible implementation returning true due parameters you read in an xml On Sat, Nov 7, 2009 at 11:38 AM, Gw wrote: > Hi people, > > Does anyone know how to dynamically add components to a form? > The types and numbers of the components are arbitrary, and will be > determined programmatically. > In one page, the form may contain 1 textbox, 2 buttons. In another page, it > may contain 2 textareas, 1 checkbox, and so on... > > Perhaps there's a framework over Wicket for this? > Lots of thanks in advance for ur assist. > > Regards, > Mike > -- Pedro Henrique Oliveira dos Santos
Re: dynamic components
Let's say... an XML file containing screen configuration file will determine the form's content. On Sat, Nov 7, 2009 at 9:30 PM, James Carman wrote: > What determines which components will be on the form? > > On Sat, Nov 7, 2009 at 8:38 AM, Gw wrote: > > Hi people, > > > > Does anyone know how to dynamically add components to a form? > > The types and numbers of the components are arbitrary, and will be > > determined programmatically. > > In one page, the form may contain 1 textbox, 2 buttons. In another page, > it > > may contain 2 textareas, 1 checkbox, and so on... > > > > Perhaps there's a framework over Wicket for this? > > Lots of thanks in advance for ur assist. > > > > Regards, > > Mike > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: dynamic components
What determines which components will be on the form? On Sat, Nov 7, 2009 at 8:38 AM, Gw wrote: > Hi people, > > Does anyone know how to dynamically add components to a form? > The types and numbers of the components are arbitrary, and will be > determined programmatically. > In one page, the form may contain 1 textbox, 2 buttons. In another page, it > may contain 2 textareas, 1 checkbox, and so on... > > Perhaps there's a framework over Wicket for this? > Lots of thanks in advance for ur assist. > > Regards, > Mike > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
dynamic components
Hi people, Does anyone know how to dynamically add components to a form? The types and numbers of the components are arbitrary, and will be determined programmatically. In one page, the form may contain 1 textbox, 2 buttons. In another page, it may contain 2 textareas, 1 checkbox, and so on... Perhaps there's a framework over Wicket for this? Lots of thanks in advance for ur assist. Regards, Mike
Insights on templating and dynamic components
Hi, I just wrote up a bit on my quest to support dynamic wicket components from template generated markup code. You'll find it here, including (Scala) code: http://www.footprint.de/fcc/2008/11/some-wicket-scala/ It should be usable from Java as well, though! Have fun! Best regards, --- Jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
