You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Chris Colman <ch...@stepaheadsoftware.com> on 2012/11/23 01:54:13 UTC
Ideas on implementing dynamic addition of components that use AJAX?
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.
Re: Ideas on implementing dynamic addition of components that use
AJAX?
Posted by Sven Meier <sv...@meiers.net>.
The markup is parsed already, see Component#getMarkup().
Sven
On 11/23/2012 08:33 AM, Chris Colman 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?
>
> If it walks the markup will Wicket also be walking it at some time later
> as well, kind of duplicating the markup walking process?
>
>> 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
>> 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
>> <ch...@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Ideas on implementing dynamic addition of components that use AJAX?
Posted by Martin Grigorov <mg...@apache.org>.
See IMarkupFilter implementations.
On Fri, Nov 23, 2012 at 12:08 PM, Chris Colman <chrisc@stepaheadsoftware.com
> wrote:
> I had a thought - is there an interface implemented that provides the
> parsing of markup? If there was then I could somehow hook into that or
> provide another implementation and avoid double parsing of the markup -
> or would that be happening too late in the lifecycle to work?
>
> > -----Original Message-----
> > From: Martin Grigorov [mailto:mgrigorov@apache.org]
> > Sent: Friday, 23 November 2012 6:47 PM
> > To: users@wicket.apache.org
> > Subject: Re: Ideas on implementing dynamic addition of components that
> use
> > AJAX?
> >
> > Hi,
> >
> >
> > On Fri, Nov 23, 2012 at 9:33 AM, Chris Colman
> > <ch...@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.
> >
> >
> > > >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
> > > ><ch...@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-unsubscribe@wicket.apache.org
> > > >For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
> >
> > --
> > Martin Grigorov
> > jWeekend
> > Training, Consulting, Development
> > http://jWeekend.com <http://jweekend.com/>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com <http://jweekend.com/>
RE: Ideas on implementing dynamic addition of components that use AJAX?
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
I had a thought - is there an interface implemented that provides the
parsing of markup? If there was then I could somehow hook into that or
provide another implementation and avoid double parsing of the markup -
or would that be happening too late in the lifecycle to work?
> -----Original Message-----
> From: Martin Grigorov [mailto:mgrigorov@apache.org]
> Sent: Friday, 23 November 2012 6:47 PM
> To: users@wicket.apache.org
> Subject: Re: Ideas on implementing dynamic addition of components that
use
> AJAX?
>
> Hi,
>
>
> On Fri, Nov 23, 2012 at 9:33 AM, Chris Colman
> <ch...@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.
>
>
> > >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
> > ><ch...@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-unsubscribe@wicket.apache.org
> > >For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com <http://jweekend.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Ideas on implementing dynamic addition of components that use AJAX?
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
>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?
Our use case is as follows:
We have a core framework (100% Java) that supports a fully hosted web
site creation and hosting cloud app. The framework includes content
management facilities (rendered by Wicket) plus sophisticated
authentication & authorization (organization context aware), entity
product management, workflow/BPM, the works etc.,
We also build specialized web apps for corporations who want to get to
market ASAP by leveraging our framework. The CMS capabilities of the
framework, rendered by Wicket allow the web devs at the various
corporations to design their own markup.
Wicket's separation of concerns between Java & Markup is perfect for
this and so long as the corporate web devs are careful not to delete the
bindings we place in their HTML (i.e. wicket:id="firstName" ... etc.,)
they can continue to edit their HTML pretty much at will.
While hard coding the component hierarchy (Panels etc.,) works for many
simple scenarios we find the external web devs often want to arrange
their HTML in ways that we hadn't thought of.
e.g. the framework provides a whole lot of small components/modules
designed to fit in a side bar. We don't want to dictate the collection
of modules they must include in the side bar. With a static component
hierarchy a side bar has a static collection of modules.
With our dynamic component hierarchy the web devs can add/remove modules
to the side bar with the simple addition/exclusion of panels via
<div wicket:id="socialNetworking"/>
<div wicket:id="latestNews"/>
Etc.,
And no changes to the Java framework is required.
A recent requirement was for a log in/account panel to be located in
different locations in the page for different clients - we didn't want
to have to assemble different Java component hierarchies for different
clients.
Some clients want a log in/account panel as a separate panel 'somewhere'
and others want it embedded in the main menu.
The dynamic assembling of the component hierarchy makes for much
cleaner, elegant and more maintainable Java code. To stick with a static
model but still support the layout/markup compositions required by many
different clients we would have to build in a hell of a lot of
conditional Java code that would need to become aware of the individual
client for which the page is being assembled - yuck!
I'm not 100% sure that Wicket was designed with this level of
flexibility from dynamic component assembly in mind but that fact that
we can pull this off speaks volumes for the Wicket architects.
>
>N
>On Nov 24, 2012 1:26 AM, "Chris Colman" <ch...@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.vaynberg@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
>> <mg...@apache.org>
>> >wrote:
>> >> Hi,
>> >>
>> >>
>> >> On Fri, Nov 23, 2012 at 9:33 AM, Chris Colman
>> >> <ch...@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
>> >>> ><ch...@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-unsubscribe@wicket.apache.org
>> >>> >For additional commands, e-mail: users-help@wicket.apache.org
>> >>>
>> >>>
>> >>>
>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >>> For additional commands, e-mail: users-help@wicket.apache.org
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Martin Grigorov
>> >> jWeekend
>> >> Training, Consulting, Development
>> >> http://jWeekend.com <http://jweekend.com/>
>> >
>>
>---------------------------------------------------------------------
>> >To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Ideas on implementing dynamic addition of components that use AJAX?
Posted by Nick Pratt <nb...@gmail.com>.
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" <ch...@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.vaynberg@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
> <mg...@apache.org>
> >wrote:
> >> Hi,
> >>
> >>
> >> On Fri, Nov 23, 2012 at 9:33 AM, Chris Colman
> >> <ch...@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
> >>> ><ch...@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-unsubscribe@wicket.apache.org
> >>> >For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>>
> >>>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >> Martin Grigorov
> >> jWeekend
> >> Training, Consulting, Development
> >> http://jWeekend.com <http://jweekend.com/>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
RE: Ideas on implementing dynamic addition of components that use AJAX?
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
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.vaynberg@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
<mg...@apache.org>
>wrote:
>> Hi,
>>
>>
>> On Fri, Nov 23, 2012 at 9:33 AM, Chris Colman
>> <ch...@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
>>> ><ch...@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-unsubscribe@wicket.apache.org
>>> >For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com <http://jweekend.com/>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Ideas on implementing dynamic addition of components that use AJAX?
Posted by Igor Vaynberg <ig...@gmail.com>.
On Thu, Nov 22, 2012 at 11:46 PM, Martin Grigorov <mg...@apache.org> wrote:
> Hi,
>
>
> On Fri, Nov 23, 2012 at 9:33 AM, Chris Colman
> <ch...@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
>> ><ch...@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-unsubscribe@wicket.apache.org
>> >For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com <http://jweekend.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Ideas on implementing dynamic addition of components that use AJAX?
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Fri, Nov 23, 2012 at 9:33 AM, Chris Colman
<ch...@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.
> >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
> ><ch...@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-unsubscribe@wicket.apache.org
> >For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com <http://jweekend.com/>
RE: Ideas on implementing dynamic addition of components that use AJAX?
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
>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?
If it walks the markup will Wicket also be walking it at some time later
as well, kind of duplicating the markup walking process?
>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
>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
><ch...@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-unsubscribe@wicket.apache.org
>For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Ideas on implementing dynamic addition of components that use AJAX?
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
>historically the components you add from auto resolvers are added via
>the autoAdd() method, not using add(). these components only exist
>during render of the page (in detach() phase all auto-added components
>are removed). the thinking here is that auto resolved components are
>not normal components. because they are resolved so late in the
>lifecycle they do not typically implement the entire lifecycle like
>onInitialize(), onConfigure(), etc may not necessarily be called. such
>components are also not meant to have their own state. because of
>these reasons we remove them at the end of the request and readd a new
>instance next time the page is rendered. these are basically
>"transient" "render-once" components.
I understand the historical treatment of components added by a component
resolver but would it work if there was, say, a mechanism whereby we
could set a flag on certain components that are added by a component
resolver to tell Wicket to treat them like first class components
instead of treating them like second class components like it does now?
In other words they would be treated as if they were added explicitly to
their parent in the contructor or onInitialize. i.e. preserved on detach
etc.,
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Ideas on implementing dynamic addition of components that use AJAX?
Posted by Igor Vaynberg <ig...@gmail.com>.
historically the components you add from auto resolvers are added via
the autoAdd() method, not using add(). these components only exist
during render of the page (in detach() phase all auto-added components
are removed). the thinking here is that auto resolved components are
not normal components. because they are resolved so late in the
lifecycle they do not typically implement the entire lifecycle like
onInitialize(), onConfigure(), etc may not necessarily be called. such
components are also not meant to have their own state. because of
these reasons we remove them at the end of the request and readd a new
instance next time the page is rendered. these are basically
"transient" "render-once" components.
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 -
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
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.
-igor
On Thu, Nov 22, 2012 at 4:54 PM, Chris Colman
<ch...@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org