IMO that idea is contrary to a very basic (and IMO very important) concept of Wicket, which is: Wicket cares only about tags which are identified as Wicket relevant. Thus, if you want to modify a tag (attribute or body), you need a Wicket component. I understand you problem, though and have no easy answer. But what you might try - it should still work, but I a haven't tested it for weeks - Wicket core already provides you several Response-Writers (NullResponse, StringResponse, etc.). You could subclass (I think it is) onRender(), re-direct the response of component into a StringResponse, do what ever you want, and finally write the StringResponse into your original response.
Juergen On Wed, 09 Mar 2005 10:46:13 -0500, Gili <[EMAIL PROTECTED]> wrote: > > Actually, it isn't a bug now that I think of it. > onComponentTagBody() is simply consuming everything until the > componentTag gets closed. Since I pass in the "width" component it > naturally consumes </td></tr> before hitting </table> > > I already have ideas on how to solve this problem. On a related > note, I really think that Wicket shouldn't always group all raw markup > into one MarkupStream.next() call. I understand you probably do this > for performance reasons but this behavior should be configurable. I can > very much see myself wanting to manipulate raw markup sometime in the > near future and in that case having it all lumped into one big String > makes it harder to process than if Wicket passes the tags into me one > at a time (like it does for ComponentTag). > > Can we add MarkupStream.setXXX() where XXX is something and it > basically tells the markup stream that from now on, return raw markups > one tag at a time. Whomever changes this value would be responsible for > changing it back once his method terminates. On a related note, > developers should blindly use markupStream.next() and assume it skips > all the raw markup in one shot, they should use: > > while (!(element instanceof ComponentTag)) > element = markupStream.next(); > > because even if this behavior is not changed, who is to say > there will be *any* raw markup to begin with? I think it's safer coding > to do as I mentioned above... > > Gili > > On Wed, 09 Mar 2005 10:12:55 -0500, Gili wrote: > > > > > As you recall, I have this HTML sniplet: > > > > <div id="wicket-contents"> > > <table id="wicket-width" border="0" > >width="100%"> > > <tr> > > <td> > > <wicket:body/> > > </td> > > </tr> > > </table> > > </div> > > > > and if my RoundCornerBorder's width is 100% I want to remove > >the <table> tag but not its children. Well, actually, it turns out I > >had my requirements wrong... I need to remove <table><tr><td> but leave > >its children... > > > > So I added extra calls to "markupStream.next()" to skip the > ><tr><td> raw markup and that worked, but I ran into a problem with > >onComponentTagBody(). It seems it digests <wicket:body/> *and* the > >following </td></tr> after it, so I cannot skip rendering of > ></td></tr>. > > > > Personally, I consider this a bug. What do you think? > > > >Gili > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Wicket-develop mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wicket-develop > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
