See IMarkupFilter implementations.
On Fri, Nov 23, 2012 at 12:08 PM, Chris Colman <chr...@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:mgrigo...@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 > > <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. > > > > > > > >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 > > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com <http://jweekend.com/>
