"Nathaniel Alfred" <[EMAIL PROTECTED]> wrote on 26.05.2005
16:34:13:
>
> I think I was too terse to make myself understand. With "in-text
replacement"
> 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
containing
> curlies for whatever reason in text nodes. I am also -1 on activating
that
> feature on a per-page. Whilst I am all for improving XSPs I would want
to
> avoid creating a second dialect. (Of course a temporary safeguard as in
[1],
> 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
be
> moved to a logicsheet. One can move a sniplet like
>
> <img>
> <xsp:attribute
name="src"><xsp:expr>source</xsp:expr></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
logicsheet
> it would silently generate <img src=""/>. However, XSLT will
signal"source"
> 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
welcome...
>
> Shall we add it then?
> Here's my +1.
>
> Cheers, Alfred.
>
> >[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105783302326147
Regards,
Jochen
