Re: [jira] Commented: (COCOON-2110) Evaluate expressions defined in cocooon-expression-language-api in Sitemap engine
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-devm=110651769909483w=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
Re: [jira] Commented: (COCOON-2110) Evaluate expressions defined in cocooon-expression-language-api in Sitemap engine
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
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-devm=110651769909483w=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
Re: [jira] Commented: (COCOON-2110) Evaluate expressions defined in cocooon-expression-language-api in Sitemap engine
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-devm=110651769909483w=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
Daniel Fagerstrom pisze:
As I wrote about in
http://marc.info/?l=xml-cocoon-devm=118683052219287w=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
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
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-devm=118683052219287w=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
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
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/
Re: [jira] Commented: (COCOON-2110) Evaluate expressions defined in cocooon-expression-language-api in Sitemap engine
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
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
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-devm=110651769909483w=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
[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.
[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_12519186
]
Jörg Heinicke commented on COCOON-2110:
---
The start chars of the expression changes to ${ for all expression languages.
The expression language gets selected by the first part like jexl above. The
same applies to JXPath. It is only the default and therefore left out. That the
expression language itself might be different sounds reasonable. So I don't
think it's more different than before.
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.
[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_12519191
]
Vadim Gritsenko commented on COCOON-2110:
-
I'm not sure I can recall this decision - to change the start char. First, it
is backward incompatible change, which means it can't be done in 2.2 - only in
2.3, if ever. And second, at this moment, in cforms samples alone, there are 56
#{foo} expressions or so. Dropping support for that would note be wise.
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.
[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_12519193
]
Jörg Heinicke commented on COCOON-2110:
---
I neither can recall it. How this one came up, Grek? I'm in favor of it though.
Backward incompatible change itself seems not to be disqualifying, see the
discussion about the environment. One can argue with public vs. private API
here though ...
In this case it should be even possible to support the #{} expressions as well
and log some deprecation message. This would allow a change in 2.2.
Let's bring it back to dev list - even if it's only for the decision of
changing the start chars.
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.
[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_12519194
]
Jörg Heinicke commented on COCOON-2110:
---
Public vs. private API does not stand a second sight. Request.getSession() is
for sure accessed very often ...
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.
