----- Original Message -----
From: "Leszek Gawron" <[EMAIL PROTECTED]>
To: <dev@cocoon.apache.org>
Sent: Thursday, October 20, 2005 10:13 PM
Subject: Re: JavaScript expressions in JXTG (was Re: svn commit: r325889) -
want it ? GOT IT
> Daniel Fagerstrom wrote:
> > Leszek Gawron wrote:
> > ...
> >
> >> I have commited an initial version of javascript support in jxtg.
> >> Looks like it's working although I have not tested it much.
> >>
> >> just as the commit message says:
> >> use @{expression} for jxtg and {js:expression} for CTemplate
> >>
> >> (CTemplate is not available without some .xconf edition. I am going to
> >> make it available soon)
> >>
> > Cool!
> >
> > Any opinions about the expression interfaces? If you find them ok I
> > think that we should move the expression abstraction to core. I didin't
> > want to do that before having got any feedback about them. The fact
> > that it was possible to use them for JS also, show IMO that they are
> > good enough.
> Generaly they are ok. I am just suspicious about the need for
> Expression.assign() method.
>
> > If we move them to core we could also start to use the expression
> > abstraction in the rest of Cocoon.
> Is there any place we need it apart from forms?
>
> >
> > So what about moving:
> >
> > o.a.c.components.expression
> > o.a.c.components.expression.javascript
> > o.a.c.components.expression.jexl
> > o.a.c.components.expression.jxpath
> >
> > to core?
> >
> > Or maybe we could keep o.a.c.components.expression.jexl in template as
> > Sylvain dislikes it ;) and jexl is not used in any other places.
> Thing is if we want consistent environment some users may want to use
> jexl in all places. People got used to jexl syntax and it would be easy
> for them to port that knowledge to other areas.
>
We at Osirion belong to the people using Jexl in other places. We currently
use it as an expression language to perform calculations on several types of
objects. We developped so called custom obejcts, that we use in an object
oriented information model, that can be executed on real data. In these
objects some of the properties are based on other properties. The calculate
them Jexl expressions can be used. They are also used in validating them.
Other applications are filtering, sorting and aggregating sets of arbitrary
objects. This can be done by several types of sorters, filters etc. One
option is sorting, filtering, aggregating by expression, which turns out to
be the most used one by far.
Our model is used to disclose any information in any organisation in a
coherent way. Cocoon is used to publish the information.
So we havily rely on Jexl and we surely like to keep it in Cocoon in a
prominent place. On the other hand we also experienced some of the drawbacks
of it. The main drawback is that is not extensible as opposed to e.g.
jxpath. The introspection of Jexl is completely closed. To solve this
problem and make everything work for us, we did some minor patches in Jexl
and now use that version.
I wonder what other objections there are to use Jexl (Sylvain apparently
dislikes it). Maybe we could make a list and change Jexl to solve these
problems. I will volunteer to help in this, of course in coorperation with
the JEXL people, although there isn't that much traffic anymore on the
mailing list.
wdyt.
Rob Berens
Osirion B.V.
Gagelveld 41
6596 CC Milsbeek
The Netherlands
Tel: +31 (0)485-54 02 03
Fax: +31 (0)485-54 02 04
E-mail: [EMAIL PROTECTED]
