Leszek Gawron wrote:
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.
It is needed for JXPath, and possibly othe expression languages that
doesn't contain assignment.
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?
It would be nice to use it in modules and in the sitemap. So that
expressions can be handled in the same way everywhere in Cocoon.
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.
Sure, not any strong opinion about it.
In some way I think that we only should move the interfaces to core and
make own blocks of the various implementations. That makes the core
smaller, OTH splitting Cocoon in smaller parts could wait until we have
moved completely to M2. Before that it is to much work to keep track on
the dependencies.
/Daniel
