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
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 onl
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 pr
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 rec
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 (o
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
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
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
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
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 int
10 matches
Mail list logo
