I found a problem with the previous algorithm and fixed it. The problem
involved Panel markup that contained some markup with wicket:id tags
*outside* the
<wicket:panel>
</wicket:panel>
element. These were resulting in components being added also but they
shouldn't. I now add an extra check with a 'processing' semaphore that,
when > 0, indicates that wicket:id tags should be processed, otherwise
they are ignored.
boolean isPanel = container instanceof Panel;
// Panels should not process markup elements outside the
// <wicket:panel> element but pages should process all markup
int processing = isPanel ? 0 : 1;
for (MarkupElement markupElement: markupElements)
{
if ( markupElement instanceof WicketTag )
{
WicketTag wicketTag = (WicketTag)markupElement;
if ( wicketTag.isPanelTag())
{
if ( wicketTag.getXmlTag().isOpen() )
processing++;
else
processing--;
}
}
else if
(
processing > 0
&&
markupElement instanceof ComponentTag )
{
ComponentTag tag = (ComponentTag)markupElement;
String rawTagId = tag.getId();
if ( rawTagId != null )
{
String tagId;
...
>-----Original Message-----
>From: Nick Pratt [mailto:nbpr...@gmail.com]
>Sent: Thursday, 29 November 2012 7:01 AM
>To: users@wicket.apache.org
>Subject: Dynamic Components
>
>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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
