Nathaniel Alfred wrote:
From: Jochen Kuhnle [mailto:[EMAIL PROTECTED]
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
