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 <b...@iswd.nl> 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 >> >> >
