>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
