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
