i think you are on the wrong track. we won't ever give you access to the raw markup because that's contrary to the whole philosophy of the framework. wicket manipulates only the tags it's attached to. if you have something really special to do you should /create/ a bunch of markup on the fly. simply write code that generates the entire body for your component tag by overriding onComponentTagBody(). for example, AbstractChoice does this for all its subclasses, generating the selection options. in other words, in this oddball case you should implement your own ad-hoc solution. for example, you can just stick raw html in your java code where you can control it completely.
jon
Gili wrote:
I assume we're talking about my idea of Wicket returning raw tags one at a time?
Redirecting StringResponse would still give me all the raw markups in one big lump right? I mean, there is no guarantee that I'd get the tags one at a time. My point is, I could take all the raw tags (in one lump) pass them through dom4j and do my own custom parsing but this is inefficient because I'd have to create my own parser, document, etc when we obviously already have one in Wicket. If I wanted to do manipulation of raw tags, having Wicket tokenize them for me would be far easier than doing it myself.
Maybe it would help rephrasing the request... Instead of MarkupStream.mutable(), I'm looking for something like MarkupStream.rawMarkup(). It would return a subclass of some kind that would return raw tags, whereas the default stream would not do this... Anyway, food for thought.
Gili
On Wed, 9 Mar 2005 17:00:46 +0100, Juergen Donnerstag wrote:
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
------------------------------------------------------- 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
