cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Kuhnle <li...@kuhnle.net>
Subject RE: [RFE] Some enhancements to XSP
Date Wed, 25 May 2005 08:23:44 GMT
"Nathaniel Alfred" <Alfred.Nathaniel@swx.com> wrote on 24.05.2005 
22:40:32:

> >-----Original Message-----
> >From: Jochen Kuhnle [mailto:lists@kuhnle.net]
> >Sent: Dienstag, 24. Mai 2005 13:45
> >To: dev@cocoon.apache.org
> >Subject: [RFE] Some enhancements to XSP
> >
> >
> >Hi, I know XSPs are supposed to go away, but I still like 'em... I 
would 
> >like to propose some enhancements, and if they're accepted also 
volunteer 
> >to implement them (including documentation and examples :).
> >
> >1. A logicsheet for cache key control to have an easy way to override 
> >"getKey". Something like:
> >
> ><key>
> >        <value><xsp:request-param name="userId"/></value>
> >        <value><xsp:request-param name="companyId"/></value>
> ></key>
> >
> >2. A logicsheet to do the same for "getValidity", so you can do:
> >
> ><validity>
> >        <file src="/etc/configfile"/>
> >        <expires seconds="3600"/>
> ></validity>
> >
> >Tags would be available for all classes in the distribution 
> >that extend SourceValidity.
> 
> We are also heavy XSP users but up to now I never came around to try
> caching.  Do just want to generate the getKey/Validity methods or did
> you forsee to have some sort of chaining/overriding mechanism?

The logic sheet would override getKey and getValidity of the server page 
(inherited from AbstractServerPage). The <key> tag should return an array 
of Serializables as key, with the array items being the Serializables 
generated by the nested <value> (or other) tags. An optimization would be 
to return a single Serializable if the key section only creates one 
Serializable.

Use cases I have come accross often are to cache different (personalized) 
versions of the server page keyed by user id or browser category (wap, 
html, pdf).

The <validity> tag would return an AggregatedValidity, with the items 
being the the Validiy Objects generated by the child tags (<file>, 
<expires>, ...). Again, as an optimiziation, if the section only creates 
one Validity, this could be returned directly.

Use cases could be caching by expiry (the server page should be 
regenerated every hour, or at midnight every day) or external 
invalidations by database updates.

I have come across these use cases quite often, hence the request for more 
convenience.

> 
> >3. A mechanism for expression replacement as in XSLT or JXTG, replacing 

> >"{expression}" with a xsp:attribute element in attributes and with a 
> >xsp:expr element in character data. This could be implemented in the 
> >PreProcessFilter of XSPMarkupLanguage. The feature would be disabled by 

> >default and enabled on a per-XSP-basis, maybe through a processing 
> >instruction.
> >
> >Example:
> >
> ><!-- Hey, this looks almost like JXTG :) -->
> ><img src="{source}" width="{width}" height="{height}"/>
> ><h1>Hello {username}</h1>
> >
> >is more readable and easier to use than
> >
> ><img>
> >        <xsp:attribute 
> >name="src"><xsp:expr>source</xsp:expr></xsp:attribute>
> >        <xsp:attribute 
> >name="width"><xsp:expr>width</xsp:expr></xsp:attribute>
> >        <xsp:attribute 
> >name="height"><xsp:expr>height</xsp:expr></xsp:attribute>
> ></img>
> ><h1>Hello <xsp:expr>username</xsp:expr></h1>
> >
> >Any comments? (I hope this hasn't been proposed already, but I 
> >didn't find anything about it)
> 
> Don't think in-text replacement is a good idea.  The preprocess would
> need too much knowledge about xsp markup in order not to try expanding
> curlies inside xsp:logic, xsp:expr etc.

I would not go so far as to analyze the tag content, I just would do 
"stupid" replacement of everything inside { and }. This would of course 
mean that "content" curlies have to be escaped somehow. If we stay with 
the XSLT syntax, this means doubling every { and }. This is a bit ugly in 
Java code ( if(expr) {{ statement; }} ), but personally I would not invent 
a new syntax, but reuse XSLT's. Of course, we could choose another more 
suitable syntax.

With the attribute replacement, you can get rid of all <xsp:attribute 
name="name"><xsp:expr>javaExpression</xsp:expr></xsp:attribute". Nearly

all of my xsp:attribute elements look like that, but since that may not be 
the case with other Cocoon users, maybe we could get some feedback?

> 
> Also for the src="{source}" shortcut I am sceptic.  It breaks when
> you want to move your <img> content markup from XSP to logicsheet.
> 

We could use the filter code to read logicsheets, too, so the new syntax 
would be available there also. Even without this, the main goal is to make 
things easier for XSP "authors". XSP style sheet "programmers" have a 
harder life :)

> But I agree that the xsp:attribute markup is too verbose.  I'd rather
> wish for the XSLT analogy:
> 
>   <xsp:attribute name="src" value="source"/>
> 
> >Regards,
> >Jochen
> 
> Looking forward to hear more from you.
> Cheers, Alfred.
> 

Because this feature would be disabled by default, we maintain 
compatibility with existing XSPs. It could be enabled if wanted. Since it 
replaces expressions in tag attributes and text nodes, these to features 
could be enabled separately. Even enablement based on tag name (like 
XSLT's strip-whitespace [1]) is possible, although IMO not necessary.

Regards,
Jochen

[1] http://www.w3.org/TR/xslt#strip

Mime
View raw message