cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: [RFE] Some enhancements to XSP
Date Wed, 25 May 2005 18:46:40 GMT
Nathaniel Alfred wrote:
>>From: Jochen Kuhnle [mailto:lists@kuhnle.net]
>>
>>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>

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

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

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 
>>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'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 
missing...

Vadim

[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105783302326147

Mime
View raw message