>> >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
