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
<[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
