cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: JavaScript expressions in JXTG (was Re: svn commit: r325889) - want it ? GOT IT
Date Fri, 21 Oct 2005 09:46:07 GMT
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.


View raw message