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
