Nathaniel Alfred wrote:
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]

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.


I think it is a bad idea to use exactly the same syntax as for XSLT because it
makes really awkward to use XSP attribute interpolation inside logicsheets.

You haven't written any XSLT producing Ant files recently, have you? :-)
Now it seems really easy to me, you simply write:

  <img src="{{foo}}"/>

in the XSLT.


You end up wasting your time figuring out which curly mountain is needed to
get the expression to be interpreted by the right engine.

It should be easy for both humans and the XSP processor to distinguish between
XSP and XSLT expressions.

I don't get your point about XSP processor. It is already dead easy for it.


I don't know AxKit in detail but I assume that them using "{foo}" syntax means
that they are not using XSLT-based logicsheets.

It's implemented in PERL, for logicsheets they have .pm files, iirc.


Anyway, we can still claim to
use a common standard by defining:

   interpolated-expr ::= '{' language-expr '}'
language-expr ::= perl-expr | '?' java-expr | '?' javascript-expr | '?' python-expr

Extra character does not add any elegance, imho.


As for backward compatibility, is is already solved by:

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


But the default value should be attribute-value-interpolation="yes", provided
we can agree on a syntax which is highly unlikely to be used in existing XSPs.

If default is "yes" by default :-) then you'll break all the installations of Cocoon out there in one shot. *Not* nice!

Hence, default must be at least configurable - in the cocoon.xconf.

Vadim

Reply via email to