You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Alfred Nathaniel <an...@apache.org> on 2007/08/11 12:23:27 UTC
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
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