On Thu, Nov 29, 2012 at 7:00 AM, Chris Colman <chr...@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-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/>
