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 Tue, 31 May 2005 13:29:55 GMT
Nathaniel Alfred wrote:
>>-----Original Message-----
>>From: Jochen Kuhnle [mailto:lists@kuhnle.net]
>>Sent: Freitag, 27. Mai 2005 15:02
>>To: dev@cocoon.apache.org
>>Subject: RE: [RFE] Some enhancements to XSP
> 
>> and "if(expr) {{{{code}}}}" really starts to look bad.
> 
> 
> XSP attribute interpolation makes on sense for Java expressions.  Therefore
> "if(expr){code}" is not really an issue.

Right


> I would suggest a syntax as "{?expr}" which must be transformed by a preprocessor
> applied to XSPs and logicsheets:

See below.


>     <img src="{?logo}.gif"/>
> ==> <img><xsp:attribute name="src"><xsp:expr>(logo)+""</xsp:expr>.gif<xsp:attribute></img>

String.valueOf(logo)


>     <h1>Hello {?username}</h1>
> ==> <h1>Hello <xsp:expr>(username)+""</xsp:expr></h1>

I'm -1 on this ATM. Let's do step at a time - first let's reduce verbosity in 
generating attributes.


> The prepocessor should not introduce any new line breaks in order to preserve
> the correct line number count for XSLT error messages from the logicsheet.
> 
> The preprocessor must understand string and character constants and nested braces.
> Here are a few valid non-trivial expressions:
> 
>     {?foo.indexOf('}')}
>     {?foo.indexOf("}")}
>     {?new String[]{"foo","bar"}[index]}
> 
> If the closing brace is missing, the preprocessor shall generate XSP code which
> leads to a compilation error:
> 
>     <h1>Hello {?username}</h1>
> ==> <h1>Hello <xsp:expr>(username)+""}</xsp:expr></h1>
> 
> The replacement can be suppressed, by duplication the "?":
> 
>     <tt>&lt;h1&gt;Hello {??username}&lt;/h1&gt;</tt> is transformed
to
>     <tt>&lt;h1&gt;Hello &lt;xsp:expr&gt;username&lt;/xsp:expr&gt;&lt;/h1&gt;</tt>

There should be no '&lt;xsp:expr&gt;', but rather '{'.


> Instead of "?" one could also use another character provided it is sufficiently
> unlikely that the sequence curly-char appears in XSP-embedded content or where 
> XSP can be embedded (XSL).  The special character should not be valid at the
> beginning of an expression at least for CSS, HTML, Java, Javascript, Perl, 
> and XSLT.  That excludes
> 
>     + " * % & ` @ ' ^ ~ ! [ $ - . ( /
> 
> but leaves as sensible alternatives
> 
>     {#expr}
>     {=expr}
>     {:expr}
>     {?expr}
> 
> Whatever special character we agree on, it should be always the same in all
> contexts and always enabled.
> 
> Any preferrences which character to use?

Yes. Given that (a) XSLT already has '{foo}' syntax, and uses '{{foo}}' for 
escaping; and given that the only other XSP implementation (AxKit) uses same 
syntax as in XSLT, I'm for using that same syntax too.

As for backward compatibility, is is already solved by:

   <xsp:page attribute-value-interpolation="no">


Re -1 above: If in future you'd want to implement interpolation in the text as 
well, we could add:

   <xsp:page text-value-interpolation="no">

(which, too, would preserve backward compatibility)


Vadim

Mime
View raw message