cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Pruy <Rainer.P...@Acrys.COM>
Subject Re: New expressions' syntax
Date Mon, 20 Aug 2007 07:52:14 GMT
Grzegorz Kossakowski schrieb:
> Rainer Pruy pisze:
>> Daniel Fagerstrom schrieb:
>>> Grzegorz Kossakowski skrev:
>>>> Daniel Fagerstrom pisze:
>>> ...
>>>
>>>> Simply choosing {} is not a solution because there will be no smooth
>>>> migration path for two reasons:
>>>>   a) some JX may break as proved above
>>>>   b) it's all or nothing situation, if someone (or we) decides to
>>>> switch to new expressions their existing applications simply break
>>>>
>>>> Such radical step has its own benefits but I'm not sure if it's
>>>> exactly what you would agree with.
>>> We are not forcing anyone to use the new unified ELs, we just offer
>>> people to do that if they feel like it. It is just a configuration
>>> setting.
>>>
>>> /Daniel
>>
>> Hmm, leaving me wonder, whether such configuration can be decided upon
>> on a per block basis.
>> Otherwise, if I'd choose using "new" EL I would be prevented from using
>> blocks that stick to "old" world and vice-versa?
> 
> I'm not sure if we have mechanism for per block configuration but I fear
> you may be right. AFAIK, main merit of Cocoon's (future) OSGi
> integration is blocks isolation.
> 
> That's why I had this intuitive to enable people mix old and new syntax.
> Any thoughts?
> 

Yes, OSGi might simplyfy per block configuration and thus reducing on
the problem.

OTH, I just read in the "Default Expression Language" thread, it might
be necessary for supporting sevaral languages in parallel.
With this, indicating the language used with a certain syntactic scope
is no longer responsibility of a (per block) configuration only.

While at xml element level, an EL can be indicated using a special
attribute, this does not help with mixed content or attributes of such
elements.

>From my point of view, this does require a special syntax for
expressions/string templates. Leading to a setup where a given syntax
({}, ${},%{},etc.) can be bound to an EL by the configuration, providing
a means for compatibility with "old" syntax bindings.
For the future I'd prefer a syntax that allows for indicting an EL by
expression/string template. A simplified syntax could be used for a
"default EL" also set with the (block level) configuration.

Not having thought it to the end, I currently imagine a syntax of say
"%tag{...}" where tag is a (prebound) indicator of an EL and "{...}" can
be used for default EL. This would also provide for a trivial escaping
if there is a "verbatim" EL that uses the expession/template as verbatim
value. (Ok, granted, it only will work for cases where balanced "{}"
will occur, other cases will need a per character escape means or a way
of specifying that a complete string or expression is to be used verbatim).

Just a view stray thoughts...

Rainer Pruy

Mime
View raw message