cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: [RFE] Some enhancements to XSP
Date Wed, 25 May 2005 18:46:40 GMT
Nathaniel Alfred wrote:
>>From: Jochen Kuhnle []
>>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:
>>       <value><xsp:request-param name="userId"/></value>
>>       <value><xsp:request-param name="companyId"/></value>
>>2. A logicsheet to do the same for "getValidity", so you can do:
>>       <file src="/etc/configfile"/>
>>       <expires seconds="3600"/>

Something is missing here... Namespace? Should be something like:

<xsp:page ... xmlns:c=".../xsp/caching">
     <xsp:request-param name="userId"/>

Element <value/> can be avoided: just concatenate contents of all nested nodes, 
and you got the key.

>>Tags would be available for all classes in the distribution 
>>that extend SourceValidity.

Sounds good.

> 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?

I'd suppose that it could merge all <key/>, <validity/> elements - so that if

some other logicsheets adds caching instructions, they are added. The only 
problem here is that in such scenario there will be a need to disable caching - 
probably using <c:disable/> tag or some such.

>>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 
>><!-- 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
>>       <xsp:attribute 
>>       <xsp:attribute 
>>       <xsp:attribute 
>><h1>Hello <xsp:expr>username</xsp:expr></h1>
>>Any comments?

I'm not in favour of <h1>Hello {username}</h1>.

>>(I hope this hasn't been proposed already, but I 
>>didn't find anything about it)

See [1].

> Don't think in-text replacement is a good idea.

I think it's great idea, and, moreover, it is already implemented in another XSP 
implementation - AxKit [1]. So implementing the feature makes sense - it will 
consolidate XSP standard.

> The preprocess would
> need too much knowledge about xsp markup in order not to try expanding
> curlies inside xsp:logic, xsp:expr etc.

Curlies (should) are always expanded in the attribute values only - same as in 
XSLT. No evaluation in any other place - so in this case it is very simple.

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

Please elaborate, what breaks and why?

> 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"/>

That can be trivially added - on top of what we have now. Not sure why it was 



View raw message