Re: New expressions' syntax
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
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
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
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
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
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
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
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
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:
#files { border-collapse: collapse; border-left: dotted black 1px; }
#files td { padding: 0.1em; border-bottom: dotted black 1px; }
.selected { background: #D0D0D0; }
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:
#files \{ border-collapse: collapse; border-left: dotted black 1px; \}
#files td \{ padding: 0.1em; border-bottom: dotted black 1px; \}
.selected \{ background: #D0D0D0; \}
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:
#files {{ border-collapse: collapse; border-left: dotted black 1px; }}
#files td {{ padding: 0.1em; border-bottom: dotted black 1px; }}
.selected {{ background: #D0D0D0; }}
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
