cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Kuhnle <>
Subject RE: [RFE] Some enhancements to XSP
Date Fri, 27 May 2005 13:02:18 GMT
"Nathaniel Alfred" <> wrote on 26.05.2005 

> I think I was too terse to make myself understand.  With "in-text 
> I meant
>     <h1>Hello {username}</h1>
> as shortcut for
>     <h1>Hello <xsp:expr>username</xsp:expr></h1>
> I am against that because it risks to break too many existing XSP 
> curlies for whatever reason in text nodes.  I am also -1 on activating 
> feature on a per-page.  Whilst I am all for improving XSPs I would want 
> avoid creating a second dialect.  (Of course a temporary safeguard as in 
> with the intention to make it the default later, is okay.)

I'd rather go for a conservative approach here. We shouldn't risk breaking 
even one existing deployed XSP. How about turning it off by default, but 
issuing a warning in the log if the page doesn't specify whether it wants 
attribute expansion or not. This can be done either by processing 
instruction or xsp:page attribute. After some time, we then can deprecate 
the not-expanding variant. We could also have the "in-text-replacement" 
variant, because we wouldn't have to worry about breaking anyting (I 
rather got used to it from JXTG...).

> I was just thinking of XSP as staging ground for code which later might 
> moved to a logicsheet.  One can move a sniplet like
>    <img>
>      <xsp:attribute 
>    </img>
> unchanged from XSP and logicsheet whilst <img src="{source}"/> needs to
> be adaption.
> But I had the misconception that there was the danger that in the 
> it would silently generate <img src=""/>.  However, XSLT will 
> as invalid expression to catch the error at compile time.
> So I changed my mind and now, I am in favor of it.

If we filter the logic sheets, too, we can still move code back and forth 
between XSP and logic sheet. There is one problem, though: since XSL uses 
curlies, too, you have to escape them even more, and "if(expr) 
{{{{code}}}}" really starts to look bad. In this case, I would rather go 
for a new syntax. Something like "~{expression}~" or more esoteric quotes, 
like the single characters << and >>, or ` and ยด. Any suggestions 

> Shall we add it then?
> Here's my +1.
> Cheers, Alfred.
> >[1]


View raw message