You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Grzegorz Kossakowski <gr...@tuffmail.com> on 2007/08/17 20:15:45 UTC
New expressions' syntax
Hi,
I would like to discuss a new syntax for expressions or more precisely for string templates that are
going to be default in Cocoon.
In order to clarify things I'll provide vocabulary that corresponds to current implementation.
Expression
Expressions are just strings that can be interpreted in certain language like Jexl or JXPath.
Expressions can contain prefix that gives hint how to interpret them. Some examples:
* jxpath:$cocoon/request - JXPath
* bean.HelperMethod("sth") - Jexl
* ${bean1.bean2} - this is _not_ an expression (more below)
String template
String templates are strings that contain both expressions (wrapped in some special characters)
and literals mixed up. Examples:
* This is literal, #{$cocoon/request}. - literal and JXPath expression wrapped in old way
* ${bean1.bean2} - only Jexl expression wrapped in old way
* Literal1 {request-param:param} Lieteral2 - two literals and sitemap expression wrapped using
{} characters.
In this mail I would like to discuss these wrapping characters for string templates we are going to
have by default at least in Template and Sitemap but very likely that also in Forms and other places
where expressions can be useful.
Currently we use {} to wrap sitemap expressions. We use #{} to wrap JXPath, ${} to wrap Jexl, @{} to
wrap Javascript expressions, all in Template only.
One of my big goals is to make you think only about one string template, one wrapping chars and
whatever you like number of expression languages you like everywhere in Cocoon. When achieving this
goal I must keep back-compatibility in mind all the time as Daniel is patiently reminding me.
I think that I have not introduced any back-incompatibility so far even I wanted several times. I
guess it's the hardest time because I'm I want to:
a) allow people migrate to new expressions both in Template and Sitemap smoothly
b) stay 100% back-compatible with old code behaviour while implementing new ways of expression
evaluation and most importantly Object Model construction
c) avoid confusion about what's new and what's old
This leads us to small but very important question: how we wrap new expressions? If I'm not wrong,
current preference has been to wrap new expressions in {}, Daniel confirms[1] this view.
My own opinion is that plain {} are ok in sitemap but will not work well in general. If choose {} as
wrapping characters everything put between this characters will be considered as expression. If you
additionally remember that all strings inside elements are treated as String templates you may start
to be warned. Take a look this[2] file's snippet:
<style type="text/css">
#files { border-collapse: collapse; border-left: dotted black 1px; }
#files td { padding: 0.1em; border-bottom: dotted black 1px; }
.selected { background: #D0D0D0; }
</style>
It's a content of jx template but obviously we don't want generator/transformer to interpret this
CSS declarations as Cocoon expressions! We would need to escape {} wrapping characters:
<style type="text/css">
#files \{ border-collapse: collapse; border-left: dotted black 1px; \}
#files td \{ padding: 0.1em; border-bottom: dotted black 1px; \}
.selected \{ background: #D0D0D0; \}
</style>
It's ugly, don't you think?
Next choice could be to use ${}. The problem with this characters is that they are already used in
Template and if we don't pick Jexl language as default it will break current templates not to
mention confusion it would cause. We could come up with %{}, !{} or whatever is not used yet.
Everyone's keyboard has lot of remaining symbols waiting for use but I wonder if we really want/need
new wrappers.
I'm stuck. Thoughts?
[1] http://marc.info/?l=xml-cocoon-dev&m=118703810504930&w=2
[2]
http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/file_explorer_template.xml
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: New expressions' syntax
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Grzegorz Kossakowski wrote:
> Currently we use {} to wrap sitemap expressions. We use #{} to wrap
> JXPath, ${} to wrap Jexl, @{} to wrap Javascript expressions, all in
> Template only.
>
> One of my big goals is to make you think only about one string template,
> one wrapping chars and whatever you like number of expression languages
> you like everywhere in Cocoon. When achieving this goal I must keep
> back-compatibility in mind all the time as Daniel is patiently reminding
> me.
I'd rather prefer to have ability to map character to expression language, and
keep ${}, #{}, @{} as default configurations for jexl, jxpath, javascript
respectively (with escape syntax like $${} or ${{}}).
Suggested syntax - be it {jxpath:foo} or ${jxpath:foo} is IMHO ugly and
unnecessarily verbose.
Vadim
Re: New expressions' syntax
Posted by Joerg Heinicke <jo...@gmx.de>.
On 17.08.2007 14:15 Uhr, Grzegorz Kossakowski wrote:
> This leads us to small but very important question: how we wrap new
> expressions? If I'm not wrong, current preference has been to wrap new
> expressions in {}, Daniel confirms[1] this view.
Hey guys, you are starting to confuse me. Up to recently I thought we
are moving to ${}. That's why I asked few days ago. Now it is {}. And
Daniel's proposal of JSR-245 points to ${} again. Yes, of course it is
pluggable, but at some point we have to decide for a default one.
Actually I'm ok with both as long as it is "unified". Be it JSTL style
or AVT style (attribute value template of XSLT).
> If choose {} as wrapping characters everything put between
> this characters will be considered as expression.
> We would need to escape {} wrapping characters:
> It's ugly, don't you think?
That's probably why it is only *attribute* value template in XSLT. It
works only in attributes and {} in attributes is highly unlikely. But
I'm ok with {{ for escaping.
> We could come up with %{}, !{} or whatever is not used yet.
I want to have fewer not more! ;)
Joerg
Re: New expressions' syntax
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Rainer Pruy pisze:
> OTH, I just read in the "Default Expression Language" thread, it might
> be necessary for supporting sevaral languages in parallel.
> With this, indicating the language used with a certain syntactic scope
> is no longer responsibility of a (per block) configuration only.
We are only talking about _default_ here that should be application or block-wide setting. If you
want to use language other than default you just write:
{languagePrefix:expression}
> While at xml element level, an EL can be indicated using a special
> attribute, this does not help with mixed content or attributes of such
> elements.
>
> From my point of view, this does require a special syntax for
> expressions/string templates. Leading to a setup where a given syntax
> ({}, ${},%{},etc.) can be bound to an EL by the configuration, providing
> a means for compatibility with "old" syntax bindings.
> For the future I'd prefer a syntax that allows for indicting an EL by
> expression/string template. A simplified syntax could be used for a
> "default EL" also set with the (block level) configuration.
>
> Not having thought it to the end, I currently imagine a syntax of say
> "%tag{...}" where tag is a (prebound) indicator of an EL and "{...}" can
> be used for default EL. This would also provide for a trivial escaping
> if there is a "verbatim" EL that uses the expession/template as verbatim
> value. (Ok, granted, it only will work for cases where balanced "{}"
> will occur, other cases will need a per character escape means or a way
> of specifying that a complete string or expression is to be used verbatim).
>
> Just a view stray thoughts...
I guess you missed my first mail[1] of this thread where I explained how one would choose language
other than default. Such syntax is already implemented.
[1] http://article.gmane.org/gmane.text.xml.cocoon.devel/74640
--
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: New expressions' syntax
Posted by Rainer Pruy <Ra...@Acrys.COM>.
Grzegorz Kossakowski schrieb:
> Rainer Pruy pisze:
>> Daniel Fagerstrom schrieb:
>>> Grzegorz Kossakowski skrev:
>>>> Daniel Fagerstrom pisze:
>>> ...
>>>
>>>> Simply choosing {} is not a solution because there will be no smooth
>>>> migration path for two reasons:
>>>> a) some JX may break as proved above
>>>> b) it's all or nothing situation, if someone (or we) decides to
>>>> switch to new expressions their existing applications simply break
>>>>
>>>> Such radical step has its own benefits but I'm not sure if it's
>>>> exactly what you would agree with.
>>> We are not forcing anyone to use the new unified ELs, we just offer
>>> people to do that if they feel like it. It is just a configuration
>>> setting.
>>>
>>> /Daniel
>>
>> Hmm, leaving me wonder, whether such configuration can be decided upon
>> on a per block basis.
>> Otherwise, if I'd choose using "new" EL I would be prevented from using
>> blocks that stick to "old" world and vice-versa?
>
> I'm not sure if we have mechanism for per block configuration but I fear
> you may be right. AFAIK, main merit of Cocoon's (future) OSGi
> integration is blocks isolation.
>
> That's why I had this intuitive to enable people mix old and new syntax.
> Any thoughts?
>
Yes, OSGi might simplyfy per block configuration and thus reducing on
the problem.
OTH, I just read in the "Default Expression Language" thread, it might
be necessary for supporting sevaral languages in parallel.
With this, indicating the language used with a certain syntactic scope
is no longer responsibility of a (per block) configuration only.
While at xml element level, an EL can be indicated using a special
attribute, this does not help with mixed content or attributes of such
elements.
>From my point of view, this does require a special syntax for
expressions/string templates. Leading to a setup where a given syntax
({}, ${},%{},etc.) can be bound to an EL by the configuration, providing
a means for compatibility with "old" syntax bindings.
For the future I'd prefer a syntax that allows for indicting an EL by
expression/string template. A simplified syntax could be used for a
"default EL" also set with the (block level) configuration.
Not having thought it to the end, I currently imagine a syntax of say
"%tag{...}" where tag is a (prebound) indicator of an EL and "{...}" can
be used for default EL. This would also provide for a trivial escaping
if there is a "verbatim" EL that uses the expession/template as verbatim
value. (Ok, granted, it only will work for cases where balanced "{}"
will occur, other cases will need a per character escape means or a way
of specifying that a complete string or expression is to be used verbatim).
Just a view stray thoughts...
Rainer Pruy
Re: New expressions' syntax
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Rainer Pruy pisze:
> Daniel Fagerstrom schrieb:
>> Grzegorz Kossakowski skrev:
>>> Daniel Fagerstrom pisze:
>> ...
>>
>>> Simply choosing {} is not a solution because there will be no smooth
>>> migration path for two reasons:
>>> a) some JX may break as proved above
>>> b) it's all or nothing situation, if someone (or we) decides to
>>> switch to new expressions their existing applications simply break
>>>
>>> Such radical step has its own benefits but I'm not sure if it's
>>> exactly what you would agree with.
>> We are not forcing anyone to use the new unified ELs, we just offer
>> people to do that if they feel like it. It is just a configuration setting.
>>
>> /Daniel
>
> Hmm, leaving me wonder, whether such configuration can be decided upon
> on a per block basis.
> Otherwise, if I'd choose using "new" EL I would be prevented from using
> blocks that stick to "old" world and vice-versa?
I'm not sure if we have mechanism for per block configuration but I fear you may be right. AFAIK,
main merit of Cocoon's (future) OSGi integration is blocks isolation.
That's why I had this intuitive to enable people mix old and new syntax. Any thoughts?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: New expressions' syntax
Posted by Rainer Pruy <Ra...@Acrys.COM>.
Daniel Fagerstrom schrieb:
> Grzegorz Kossakowski skrev:
>> Daniel Fagerstrom pisze:
> ...
>
>> Simply choosing {} is not a solution because there will be no smooth
>> migration path for two reasons:
>> a) some JX may break as proved above
>> b) it's all or nothing situation, if someone (or we) decides to
>> switch to new expressions their existing applications simply break
>>
>> Such radical step has its own benefits but I'm not sure if it's
>> exactly what you would agree with.
>
> We are not forcing anyone to use the new unified ELs, we just offer
> people to do that if they feel like it. It is just a configuration setting.
>
> /Daniel
Hmm, leaving me wonder, whether such configuration can be decided upon
on a per block basis.
Otherwise, if I'd choose using "new" EL I would be prevented from using
blocks that stick to "old" world and vice-versa?
Rainer Pruy
Re: New expressions' syntax
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom pisze:
...
>>> Next choice could be to use ${}. The problem with this characters is
>>> that they are already used in Template and if we don't pick Jexl
>>> language as default it will break current templates not to mention
>>> confusion it would cause. We could come up with %{}, !{} or whatever
>>> is not used yet. Everyone's keyboard has lot of remaining symbols
>>> waiting for use but I wonder if we really want/need new wrappers.
>>
>> I woulf be OK, with chosing Jexl as default EL and using "${}", but I
>> prefer "{}".
>
> Daniel, what about back incompatibility, then?
It is plugable, so I don't see that we get any back incompatibility. If
you prefer the current way you can use that. If you prefer the new way,
you can use that.
There is no way to have a unified EL that can be used everywhere and
includes both the sitemap and the JXTG syntax.
> Simply choosing {} is not a solution because there will be no smooth
> migration path for two reasons:
> a) some JX may break as proved above
> b) it's all or nothing situation, if someone (or we) decides to switch
> to new expressions their existing applications simply break
>
> Such radical step has its own benefits but I'm not sure if it's exactly
> what you would agree with.
We are not forcing anyone to use the new unified ELs, we just offer
people to do that if they feel like it. It is just a configuration setting.
/Daniel
Re: New expressions' syntax
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom pisze:
> Which IMO is a little bit less ugly than the "\{", "\}" escaping
> mechanism. And furthermore you should have most of your CSS in own files
> that you include, shouldn't you.
I agree it looks better.
I lend this code from our samples. There are even long JS snippets in JX templates 8-)
> Looking at the parsing code I get the impression that "}}" -> "}" isn't
> implemented correctly.
Apart from who is going to fix it, could you file an issue?
>> Next choice could be to use ${}. The problem with this characters is
>> that they are already used in Template and if we don't pick Jexl
>> language as default it will break current templates not to mention
>> confusion it would cause. We could come up with %{}, !{} or whatever
>> is not used yet. Everyone's keyboard has lot of remaining symbols
>> waiting for use but I wonder if we really want/need new wrappers.
>
> I woulf be OK, with chosing Jexl as default EL and using "${}", but I
> prefer "{}".
Daniel, what about back incompatibility, then?
Simply choosing {} is not a solution because there will be no smooth migration path for two reasons:
a) some JX may break as proved above
b) it's all or nothing situation, if someone (or we) decides to switch to new expressions their
existing applications simply break
Such radical step has its own benefits but I'm not sure if it's exactly what you would agree with.
--
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: New expressions' syntax
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
...
> I want
> to:
> a) allow people migrate to new expressions both in Template and
> Sitemap smoothly
> b) stay 100% back-compatible with old code behaviour while
> implementing new ways of expression evaluation and most importantly
> Object Model construction
> c) avoid confusion about what's new and what's old
>
> This leads us to small but very important question: how we wrap new
> expressions? If I'm not wrong, current preference has been to wrap new
> expressions in {}, Daniel confirms[1] this view.
>
> My own opinion is that plain {} are ok in sitemap but will not work well
> in general. If choose {} as wrapping characters everything put between
> this characters will be considered as expression. If you additionally
> remember that all strings inside elements are treated as String
> templates you may start to be warned. Take a look this[2] file's snippet:
>
> <style type="text/css">
> #files { border-collapse: collapse; border-left: dotted black 1px; }
> #files td { padding: 0.1em; border-bottom: dotted black 1px; }
> .selected { background: #D0D0D0; }
> </style>
>
> It's a content of jx template but obviously we don't want
> generator/transformer to interpret this CSS declarations as Cocoon
> expressions! We would need to escape {} wrapping characters:
>
> <style type="text/css">
> #files \{ border-collapse: collapse; border-left: dotted black 1px; \}
> #files td \{ padding: 0.1em; border-bottom: dotted black 1px; \}
> .selected \{ background: #D0D0D0; \}
> </style>
>
> It's ugly, don't you think?
The DefaultStringTemplateParser is actually implementing the escaping
mechanism from atribute value templates in XSLT
(http://www.w3.org/TR/xslt#dt-attribute-value-template. So the example
rather becomes:
<style type="text/css">
#files {{ border-collapse: collapse; border-left: dotted black 1px; }}
#files td {{ padding: 0.1em; border-bottom: dotted black 1px; }}
.selected {{ background: #D0D0D0; }}
</style>
Which IMO is a little bit less ugly than the "\{", "\}" escaping
mechanism. And furthermore you should have most of your CSS in own files
that you include, shouldn't you.
Looking at the parsing code I get the impression that "}}" -> "}" isn't
implemented correctly.
> Next choice could be to use ${}. The problem with this characters is
> that they are already used in Template and if we don't pick Jexl
> language as default it will break current templates not to mention
> confusion it would cause. We could come up with %{}, !{} or whatever is
> not used yet. Everyone's keyboard has lot of remaining symbols waiting
> for use but I wonder if we really want/need new wrappers.
I woulf be OK, with chosing Jexl as default EL and using "${}", but I
prefer "{}".
/Daniel
> I'm stuck. Thoughts?
>
> [1] http://marc.info/?l=xml-cocoon-dev&m=118703810504930&w=2
> [2]
> http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/file_explorer_template.xml
>
>