Chris
Ive been following this thread with interest - what is the use case that
drives your need to add components dynamically - why can't you just add a
SytemPanel in the panel constructor - is your HTML markup being generated
outside of your Wicket app?
N
On Nov 24, 2012 1:26 AM, "Chris Colman" <chr...@stepaheadsoftware.com>
wrote:
> Wow! That was a bit too easy!
>
> Here's how to override onInitialize to dynamically add components to a
> page that are specified in the markup:
>
> protected void onInitialize()
> {
> super.onInitialize();
>
> IMarkupFragment markupElements = getMarkup();
>
> for (MarkupElement markupElement: markupElements)
> {
> if ( markupElement instanceof ComponentTag )
> {
> ComponentTag tag =
> (ComponentTag)markupElement;
> String tagId = tag.getId();
> System.out.println("Markup Element: " +
> tag.getName() + " ID: " + tagId);
>
> if ( tagId != null )
> {
> if (
> tagId.equals("systemPanel"))
> {
> add(new
> SystemPanel("systemPanel"));
> }
> }
> }
> }
> }
>
> In this example "systemPanel" represents the ID of a single component
> that should be added dynamically in onInitialize if it is discovered in
> the markup.
>
> It could be easily enhanced to support multiple dynamic components by
> providing a set of IDs that represent components that should be
> dynamically added and then add them when they are discovered during
> onInitialize.
>
> This could easily be applied to an application's Panel base class to
> work inside Panels in addition to pages.
>
>
> My only concern was that we're adding another iteration process to the
> page construction cycle - iterating through all MarkupElements of the
> markup of a component each time it's onInitialize is called but I guess
> it's not that much of an issue. I was hoping to 'piggy back' the
> processing onto some other process that is already iterating the markup
> elements but I haven't found a suitable spot for that yet.
>
>
> >-----Original Message-----
> >From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com]
> >Sent: Saturday, 24 November 2012 12:33 PM
> >To: users@wicket.apache.org
> >Subject: Re: Ideas on implementing dynamic addition of components that
> use
> >AJAX?
> >
> >On Thu, Nov 22, 2012 at 11:46 PM, Martin Grigorov
> <mgrigo...@apache.org>
> >wrote:
> >> Hi,
> >>
> >>
> >> On Fri, Nov 23, 2012 at 9:33 AM, Chris Colman
> >> <chr...@stepaheadsoftware.com>wrote:
> >>
> >>> >starting with wicket 1.5, however, components are able to resole
> their
> >>> >markup earlier in their lifecycle. the reason auto resolved
> components
> >>> >are added so late and treated specially was because the markup was
> >>> >only available during render. if you are using 1.5 or 6 you can
> build
> >>> >your own mechanism. something that kicks off a page/panel's
> >>> >oninitialize(), gets the markup, walks it, and adds any components
> -
> >>>
> >>> Would it be walking the markup as raw XHTML or will parsed element
> >>> objects be available at this point?
> >>>
> >>
> >> You have to use #getMarkup() or #getAssociatedMarkup(), so the result
> is
> >> already parsed (IMarkupFragment).
> >>
> >>
> >>>
> >>> If it walks the markup will Wicket also be walking it at some time
> later
> >>> as well, kind of duplicating the markup walking process?
> >>>
> >>
> >> Wicket walks the markup of the whole page for every render of the
> page.
> >> In Ajax requests only the markup of the repainted components is
> >traversed.
> >>
> >>
> >>>
> >>> >maybe ones you mark by special tags in your own namespace. the
> problem
> >>> >here is that even if you can find these components you may still
> not
> >>> >be able to put them into the right parent because in onInitialize()
> >>> >the parent may not yet be added to the container. so perhaps you
> >>>
> >>
> >> I think this is not correct. In #onInitialize() you have access to
> the
> >> markup of the current component and access to the Page instance, i.e.
> you
> >> have access to all parents between the current component and the Page
> >> instance.
> >
> >it is correct. i am not talking about the component on which
> >onInitialize() is being called... suppose you have a page that
> >implements the mechanism and your markup is like this:
> >
> ><body><div wicket:id="foo"><wicket:something/></div>
> >
> >what i meant is that inside the page's onInitialize() the component
> >"foo" may not have yet been added so the wicket:something component
> >cannot be properly put into it....
> >
> >in this case the page's subclass' onInitialize() may add "foo" or
> >onConfigure() can add "foo" or some other component if the hierarchy
> >is deeper.
> >
> >-igor
> >
> >>
> >>
> >>> >should have some mechanism that kicks off when
> page#onComponentAdded()
> >>> >is called. you can pull the newly added component's markup, see if
> it
> >>> >has any of these special components defined as a child of the
> >>> >components markup, and add them right there. since you are doing
> this
> >>> >early on these components will have normal lifecycle and should
> work
> >>> >just like any other component.
> >>> >
> >>> >hope this helps you get started. keep us in the loop.
> >>>
> >>> Sounds so crazy that it just might work ;)
> >>>
> >>> >
> >>> >-igor
> >>> >
> >>> >
> >>> >On Thu, Nov 22, 2012 at 4:54 PM, Chris Colman
> >>> ><chr...@stepaheadsoftware.com> wrote:
> >>> >> We've been using Wicket since version 1.3 and have been using the
> >>> >> IComponentResolver interface with great effect to allow the web
> >>> >> designers to effectively 'plug and play' with the Wicket
> components.
> >>> >>
> >>> >> We have multiple layouts using Wicket's 'variation' feature. Each
> >>> >> designer can build up a different collection of components in any
> >>> >> particular variation as they like - all without changing the Java
> >>> code.
> >>> >>
> >>> >> Normally, without using IComponentResolver, the Java code to
> support
> >>> >> such flexibility would be mind boggingly complex and ugly but
> with an
> >>> >> IComponentResolver we simply have code that's capable of
> >>> instantiating
> >>> >> any component anywhere - and it works and the resulting code is
> >>> >> extremely elegant.
> >>> >>
> >>> >> While we use lots of AJAX it is restricted to components that are
> >>> >> explicitly added to components i.e. not added dynamically via the
> >>> >> component resolver because such components are not able to
> contribute
> >>> >> anything to the <head> section.
> >>> >>
> >>> >> This is starting to become a bit of a problem as we want some of
> the
> >>> >> more advanced components (with AJAX) to take part in the 'plug
> and
> >>> play'
> >>> >> flexibility. We also are starting to get into using Twitter
> Bootstrap
> >>> >> with Wicket and much of the 'funkiness' in some of those
> components
> >>> >> comes from JS that needs to be injected into the header.
> >>> >>
> >>> >> Is anyone else using this 'plug and play' capability of Wicket
> made
> >>> >> available via the IComponentResolver interface or is everyone
> >>> sticking
> >>> >> to the rigid 1 to 1 relationship between markup and the
> corresponding
> >>> >> statically coded Java component hierarchy? (which we found quite
> >>> >> constricting after a few weeks =] )
> >>> >>
> >>> >> I understand that there are some workarounds suggested for
> empowering
> >>> >> AJAX in dynamically added components but they seem to involve
> >>> manually
> >>> >> parsing markup in the onInitialize method and then explicitly
> adding
> >>> any
> >>> >> required components there - it sounds non ideal and would result
> in
> >>> an
> >>> >> extra parse of all page and panel markups I would think - which
> may
> >>> >> affect performance. Would we be parsing raw XHTML at that stage
> or
> >>> would
> >>> >> a preparsed DOM be available to search through?
> >>> >>
> >>> >> What is the fundamental issue with the Wicket architecture that
> >>> prevents
> >>> >> dynamically resolved components from contributing to the header?
> >>> >>
> >>> >> Is one of the causes the fact that by the time the
> ComponentResolver
> >>> is
> >>> >> being called the header has already been rendered to the response
> >>> stream
> >>> >> and so once body rendering commences no more header injection is
> >>> >> possible?
> >>> >>
> >>> >> If so, that could probably (thinking out aloud without an in
> depth
> >>> >> knowledge of Wicket's internals =] ) be solved by splitting the
> >>> >> rendering into two streams: header injection goes to current
> output
> >>> >> stream while body rendering goes to a temporary 'body' stream.
> When
> >>> the
> >>> >> page render is complete the output of the body is then appended
> to
> >>> the
> >>> >> current stream, after the header rendering. This would allow
> header
> >>> >> injection to continue during processing of the body markup
> because
> >>> both
> >>> >> are not being sequentially output to the same stream.
> >>> >>
> >>> >> There was mention of another issue - something about auto added
> >>> >> (component resolver) objects being removed after rendering so
> they
> >>> are
> >>> >> not there when AJAX actions occur. I don't fully understand the
> >>> details
> >>> >> of this or why it is necessary. Maybe this devs could offer more
> >>> advice
> >>> >> on this.
> >>> >
> >>>
> >---------------------------------------------------------------------
> >>> >To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>> >For additional commands, e-mail: users-h...@wicket.apache.org
> >>>
> >>>
> >>>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >> Martin Grigorov
> >> jWeekend
> >> Training, Consulting, Development
> >> http://jWeekend.com <http://jweekend.com/>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >For additional commands, e-mail: users-h...@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
