Re: Proposal: New XHTML parser allows more granular decorating

I agree, performance is the #1 issue here - but strangely enough Aslak 
asked for this just last night at the OpenSymphony BOF, and I've never 
had anyone ask for it before - great minds.

Definitely should be optional.

I think a lot of what you're trying to do here can be done with content 
blocks too though, have you explored that?

Cheers,
Mike
--
ATLASSIAN - http://www.atlassian.com/

Confluence - the professional J2EE wiki - tried it yet?
http://www.atlassian.com/confluence/

On 07/05/2004, at 12:44 AM, Joe Walnes wrote:

> A couple of points to add:
> - If you use NekoHTML this will work with valid HTML as well as XHTML.
> - Performance will go down. I know, I've done it. It should be an 
> optional feature.
>
> Gets a thumbs up from me.
>
> -joe
>
> James Cook wrote:
>
>> I often find the all-or-nothing sitemesh decorator tags to be too
>> restrictive. We can import the head or the body or the title, and 
>> that's
>> about it (besides some meta properties). I end up having to stick
>> page-specific script and styles in the body of my page which I find 
>> kind of
>> kludgy.
>>
>> I was thinking that I would like to have a decorator tag that accepts 
>> XPATH
>> statements that allow me to pull a specific section of my target HTML 
>> into
>> the decorator. Something like:
>>
>> <decorator:xpath name="/html/body/div[@id='portlet']" />
>>
>> Of course, this approach wouldn't be useful to developers not working 
>> with
>> validatable XML, but many of us have made the transition.
>>
>> So in order for this to work well it will require:
>>
>> 1. A new parser that is nothing more than a standard XML parser.
>> 2. A new tag that uses standard XPath syntax.
>>
>> It shouldn't take more than an evening or two to put together. The 
>> main
>> issue will be performance. The XML parser should be extremely fast 
>> and a new
>> one shouldn't be instantiated for each request. Perhaps an object 
>> pool of
>> parsers is needed.
>>
>> Anyone see any obstacles to this approach?
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by Sleepycat Software
>> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
>> deliver
>> higher performing products faster, at low TCO.
>> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
>> _______________________________________________
>> Opensymphony-sitemesh mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/opensymphony-sitemesh
>>
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
> deliver
> higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Opensymphony-sitemesh mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-sitemesh
>



-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3