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
