You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Vadim Gritsenko (JIRA)" <ji...@apache.org> on 2007/08/11 03:47:42 UTC
[jira] Commented: (COCOON-2110) Evaluate expressions defined in
cocooon-expression-language-api in Sitemap engine
[ https://issues.apache.org/jira/browse/COCOON-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519184 ]
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.
> Evaluate expressions defined in cocooon-expression-language-api in Sitemap engine
> ---------------------------------------------------------------------------------
>
> Key: COCOON-2110
> URL: https://issues.apache.org/jira/browse/COCOON-2110
> Project: Cocoon
> Issue Type: New Feature
> Components: - Components: Sitemap, - Expression language
> Affects Versions: 2.2-dev (Current SVN)
> Reporter: Grzegorz Kossakowski
> Assignee: Grzegorz Kossakowski
> Fix For: 2.2-dev (Current SVN)
>
>
> Description of the task is relatively simple; all I want to achieve is to make possible following construct in sitemap:
> <map:transform type="xslt">
> <map:parameter name="request_param" value="${cocoon/request/some_param}"/>
> </map:transform>
> assuming that JXPath (used above) is default EL of choice. Of course one would be able to use following construct:
> <map:transform type="xslt">
> <map:parameter name="request_param" value="${jexl:cocoon.request.some_param}"/>
> </map:transform>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (COCOON-2110) Evaluate expressions defined
in cocooon-expression-language-api in Sitemap engine
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Hi Alfred,
Alfred Nathaniel pisze:
> On Sat, 2007-08-11 at 11:22 +0200, Grzegorz Kossakowski wrote:
>
>> 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.
>
> I also don't see the benefit of extending the sitemap syntax. The
> existing {input-module:parameter} syntax is flexible enough to support
> {jexl:cocoon.request.some_param} and {jxpath:cocoon/request/some_param},
> and that is not much harder to read or write than the ${} and #{}
> equivalents.
Actually, one of my goals for GSoC project is to get rid of input modules completely and only
support expression evaluation. As for now, I'm _not_ going to remove old code handling input modules
from cocoon-sitemap-impl but only add possibility to evaluate new refactored expressions.
Decision about my goals has been discussed earlier.
> Besides it avoids all problems where you would want to have a literal $
> or # immediately followed by an input module expression. (Although I
> cannot think just now of an example where that would occur.)
Why not use escaping? It's already supported.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: [jira] Commented: (COCOON-2110) Evaluate expressions defined
in cocooon-expression-language-api in Sitemap engine
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom pisze:
> As I wrote about in
> http://marc.info/?l=xml-cocoon-dev&m=118683052219287&w=2 we already
> (since maybe two years ago) has a migration path from the old to the new
> syntax.
As you see almost nobody has known that such migration path exists so, in a fact, there was not any.
Lack of documentation is serious obstacle especially in such situations.
> As the string template readers in template is plugable. In that
> implementation we actually use {} for the new syntax (following XSLT) as
> people seemed to prefer that back then. This is of course not written in
> stone, we could use ${} instead if that is what people prefer now. If we
> use ${} we more or less have to have JEXL as default expression language
> implementation, otherwise it will be highly confusing.
I wanted to use ${} to distinguish old sitemap expressions from new one. Since we somehow agreed to
use StringTemplateParser functionality the choice of expression handling will be done not by using
one or another syntax but by configuring parser. Having said that I think that use of $ sign will be
redundant. What do you think?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection ***
*** incessantly so I'll not be able to respond to e-mails ***
*** regularly and my work will be somehow irregular. ***
*** I'm already trying to switch ISP but it will take handful amount of time. ***
Re: [jira] Commented: (COCOON-2110) Evaluate expressions defined
in cocooon-expression-language-api in Sitemap engine
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Joerg Heinicke pisze:
>> I wonder what exactly will it be when everything is unified: {} or
>> ${}? I thought it's the latter, also the issue description seems to
>> point on this.
>
> The latter one because it's already used in Template and this way new
> expressions can be evaluated alongside old ones. This way we can provide
> smooth migration path.
As I wrote about in
http://marc.info/?l=xml-cocoon-dev&m=118683052219287&w=2 we already
(since maybe two years ago) has a migration path from the old to the new
syntax. As the string template readers in template is plugable. In that
implementation we actually use {} for the new syntax (following XSLT) as
people seemed to prefer that back then. This is of course not written in
stone, we could use ${} instead if that is what people prefer now. If we
use ${} we more or less have to have JEXL as default expression language
implementation, otherwise it will be highly confusing.
/Daniel
Re: [jira] Commented: (COCOON-2110) Evaluate expressions defined
in cocooon-expression-language-api in Sitemap engine
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Joerg Heinicke pisze:
> I wonder what exactly will it be when everything is unified: {} or ${}?
> I thought it's the latter, also the issue description seems to point on
> this.
The latter one because it's already used in Template and this way new expressions can be evaluated
alongside old ones. This way we can provide smooth migration path.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: [jira] Commented: (COCOON-2110) Evaluate expressions defined
in cocooon-expression-language-api in Sitemap engine
Posted by Joerg Heinicke <jo...@gmx.de>.
On 11.08.2007 6:23 Uhr, Alfred Nathaniel wrote:
> On Sat, 2007-08-11 at 11:22 +0200, Grzegorz Kossakowski wrote:
Thanks for the summary, Grek.
>> 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.
Introducing #{} does indeed make no sense.
> The existing {input-module:parameter} syntax is flexible enough to support
> {jexl:cocoon.request.some_param} and {jxpath:cocoon/request/some_param},
> and that is not much harder to read or write than the ${} and #{}
> equivalents.
I wonder what exactly will it be when everything is unified: {} or ${}?
I thought it's the latter, also the issue description seems to point on
this.
Joerg
Re: [jira] Commented: (COCOON-2110) Evaluate expressions defined
in cocooon-expression-language-api in Sitemap engine
Posted by Alfred Nathaniel <an...@apache.org>.
On Sat, 2007-08-11 at 11:22 +0200, Grzegorz Kossakowski wrote:
> 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.
I also don't see the benefit of extending the sitemap syntax. The
existing {input-module:parameter} syntax is flexible enough to support
{jexl:cocoon.request.some_param} and {jxpath:cocoon/request/some_param},
and that is not much harder to read or write than the ${} and #{}
equivalents.
Besides it avoids all problems where you would want to have a literal $
or # immediately followed by an input module expression. (Although I
cannot think just now of an example where that would occur.)
Cheers, Alfred.
Re: [jira] Commented: (COCOON-2110) Evaluate expressions defined
in cocooon-expression-language-api in Sitemap engine
Posted by Grzegorz Kossakowski <gk...@apache.org>.
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.
Thanks for bringing this. I'm looking now on this stuff and wonder how we should integrate old
sitemap mechanisms. Do I have right impression that I would have to implement StringTemplateParser
for old syntax?
What makes me wonder is that ErrorHolder class. I really don't understand it's purpose and our
archives don't help in this case.
ErrorHoler is used when is caught java.lang.Error so it's stored in ErrorHolder this class is
rethrown. According to javadocs:
An Error is a subclass of Throwable that indicates serious problems that a reasonable application
should not try to catch. Most such errors are abnormal conditions. The ThreadDeath error, though a
"normal" condition, is also a subclass of Error because most applications should not try to catch
it.
this exception should be never caught. What's the secret here?
>> 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.
You are right, I misinterpreted things.
>
> 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.
What about deprecating?
> 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.
I understand your concerns and I agree it should be quite easy to reuse existing mechanisms. The
only doubt remains is about ErrorHolder.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection ***
*** incessantly so I'll not be able to respond to e-mails ***
*** regularly and my work will be somehow irregular. ***
*** I'm already trying to switch ISP but it will take handful amount of time. ***
Re: [jira] Commented: (COCOON-2110) Evaluate expressions defined
in cocooon-expression-language-api in Sitemap engine
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom pisze:
> 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.
After sleeping with this problem in mind I'm starting to wonder, too. ;-)
It's good that nobody have seen this code that made gluing possible, it's nightmare...
> No, not without a detailed evaluation of alternative solutions, a cost
> and benefit analyze of the change and a vote.
Ok, enough points to distance me from introducing back incompatibility :)
> Are you starting to see some pattern in my responses to your suggestions
> about create back incompatibility ;)
There is another one: When I start to talk about back incompatibility it's a sign I'm stuck and need
to talk with someone more experienced to get an advice. ;)
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection ***
*** incessantly so I'll not be able to respond to e-mails ***
*** regularly and my work will be somehow irregular. ***
*** I'm already trying to switch ISP but it will take handful amount of time. ***
Re: [jira] Commented: (COCOON-2110) Evaluate expressions defined
in cocooon-expression-language-api in Sitemap engine
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
Re: [jira] Commented: (COCOON-2110) Evaluate expressions defined
in cocooon-expression-language-api in Sitemap engine
Posted by Grzegorz Kossakowski <gk...@apache.org>.
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 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.
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?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection ***
*** incessantly so I'll not be able to respond to e-mails ***
*** regularly and my work will be somehow irregular. ***
*** I'm already trying to switch ISP but it will take handful amount of time. ***
Re: [jira] Commented: (COCOON-2110) Evaluate expressions defined
in cocooon-expression-language-api in Sitemap engine
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
Re: [jira] Commented: (COCOON-2110) Evaluate expressions defined
in cocooon-expression-language-api in Sitemap engine
Posted by Grzegorz Kossakowski <gk...@apache.org>.
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. I believe that it was
Sylvain who proposed[2] prefixes for languages, first time. Then it was Reinhard who followed up[3]
Sylvain's idea:
A.) Rewrite/refactor JXTemplate
- break it up in smaller, easier understandable/maintainable pieces
- deprecate #{} syntax and make expression languages plugable as
Sylvain suggested
- investigate the performance problems (I guess there are only
problems if macros are used)
- add the missing things from above
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.
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.
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?
[1] http://article.gmane.org/gmane.text.xml.cocoon.cvs/17868
[2] http://article.gmane.org/gmane.text.xml.cocoon.devel/42659
[3] http://article.gmane.org/gmane.text.xml.cocoon.devel/42857
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/