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 Fri, 17 Aug 2007 07:33:10 GMT
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom pisze:
>> Grzegorz Kossakowski skrev:
>>> Vadim Gritsenko (JIRA) pisze:
>>>
>>> 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.
>
> Daniel, I implemented what you proposed
Good.
> but not committed yet due to regression it introduces. Basically, I 
> implemented handling of sitemap expressions in 
> LegacyStringTemplateParser (JXTGStringTemplateParser in the past) and 
> it's seems to work ok with basic tests. However, 
> LegacyStringTemplateParser is also used in Template block so, as 
> result of my changes, one will be able to evaluate sitemap expressions 
> in templates. It's not that bad but it introduces small regression.
One of the points with plugability is that you can have several 
implementations of the interface ;)

I suggest that you leave LegacyStringTemplateParser as it was before and 
put your new code in a LegacySitemapStringTemplateParser that only is 
used in the sitemap. Then you of course need to see if you get any 
regression in the sitemap.

But I wonder why you want to combine the JXTG and sitemap template 
syntax at all, why not just people chose between the old syntax and the 
new unified syntax. I suggest that you start a new less technical thread 
about how you want to have the expression syntax in the sitemap and the 
templates, so that the rest of the community can have opinions.
> With old implementation of JXTGStringTemplateParser it was possible to 
> escape "{" character but not mandatory. With new implementation it's 
> mandatory because it will be parsed as sitemap expression otherwise. I 
> tried to search for all occurrences of such unescaped "{" with this 
> command:
> find | xargs grep "http://apache.org/cocoon/templates/jx/1.0" -l | 
> xargs grep -E "<\?xml" -l | xargs grep -E "[^#\$][{]" -l | grep -E 
> --invert-match ".svn|target"
>
> and got following results:
> ./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/dreamteam/content/teamTemplate.jx

>
> ./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/file_explorer_template.xml

>
> ./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/inplace_edit_template.xml

>
> ./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/datasource_chooser_template.xml

>
> ./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/dynamicrepeater_template.xml

>
> ./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/sampletree_template.xml

>
> ./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/xmlresult_template.xml

>
> ./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/carselector_template.xml

>
> ./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/multipage_template.xml

>
> ./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/xdoceditor_template.xml

>
> ./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/tasktree_template.xml

>
> ./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/dynamicrepeater_dojo_template.xml

>
> ./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/dynamicrepeaters_dojo_template.xml

>
> ./blocks/cocoon-template/cocoon-template-sample/src/main/resources/COB-INF/view/caching2.jx

>
> ./blocks/cocoon-template/cocoon-template-sample/src/main/resources/COB-INF/view/caching3.jx

>
> ./blocks/cocoon-template/cocoon-template-sample/src/main/resources/COB-INF/view/caching1.jx

>
> ./blocks/cocoon-template/cocoon-template-sample/src/main/resources/COB-INF/view/caching4.jx

>
> ./blocks/cocoon-ajax/cocoon-ajax-impl/src/main/resources/org/apache/cocoon/ajax/resources/macros/timedbrowserupdater.xml

>
>
> Not that much files to fix on our side but I'm wondering about our 
> users. What do you think? Can we go on with such regression?
No, not without a detailed evaluation of alternative solutions, a cost 
and benefit analyze of the change and a vote.

Are you starting to see some pattern in my responses to your suggestions 
about create back incompatibility ;)

/Daniel


Mime
View raw message