cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [jira] Commented: (COCOON-2110) Evaluate expressions defined in cocooon-expression-language-api in Sitemap engine
Date Sat, 11 Aug 2007 11:07:59 GMT
Grzegorz Kossakowski skrev:
> Vadim Gritsenko (JIRA) pisze:
>> Vadim Gritsenko commented on COCOON-2110: 
>> -----------------------------------------
>>
>> Don't we have a history of using #{foo} for jxpath and ${foo} for 
>> jexl? Doing it differently
>> would just result in more confusion. I'd rather have it more uniform 
>> throughout.
> 
> Actually, such syntax is supported[1] in our code for almost two years 
> now.

The new syntax is supported but it is plugable and the default settings 
is using the old syntax. I didn't find any detailed design discussion 
about the design in the archives, the idea is suggested in 
http://marc.info/?l=xml-cocoon-dev&m=110651769909483&w=2.

For the actual implementation, the parsing of a string with embedded 
expression calls (a string template) is plugable using the interface 
o.a.c.template.expression.StringTemplateParser. The current syntax is 
handles by JXTGStringTemplateParser and the new one by 
DefaultStringTemplateParser. The choice of string template parser is 
done in 
http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-template/cocoon-template-impl/src/main/resources/META-INF/cocoon/avalon/cocoon-template.xconf.



The whole string template mechanism (the package 
o.a.c.template.expression) could preferably be reused in the sitemap as 
well. To do this the package needs to be moved to the core 
(cocoon-expression-language) and refactored a little bit, the 
dependencies on o.a.c.template.environment.ParsingContext and 
o.a.c.template.environment.ErrorHolder needs to be removed and a more 
appropriate package name should be found.

...
> To sum up, new syntax has been introduced during refactoring of Template 
> block and since community already voted to switch to refactored code it 
> also voted for new syntax.

The vote was not about removing the current syntax. It was about 
switching default implementation of the JXTG concept.

> Speaking about myself I prefer much more language prefixes and I think 
> we should go for it. The question that we need to answer is if we want 
> to support #{} syntax in sitemap? Since it was never there I don't think 
> it makes sense to do so.

Using the string template mechanism in the sitemap we get the current 
JXTG syntax for free, but I would advice users to not use it.

> I would prefer to just create migration guide that would clarify current 
> situation of expressions evaluation and would advice to use new syntax 
> everywhere. Also, switching to new syntax is really trivial, it involves 
> find & replace operation based on simple regexp. Is it a really big deal 
> if it's well described?

I'm all for recommending using the new unified expression mechanism and 
for having a migration guide. But I'm -1 for forcing people to switch 
immediately, especially as we already have a mechanism for making the 
syntax plugable.

/Daniel


Mime
View raw message