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


Reply via email to