You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by br...@apache.org on 2005/10/17 15:24:53 UTC
svn commit: r325889 -
/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml
Author: bruno
Date: Mon Oct 17 06:24:48 2005
New Revision: 325889
URL: http://svn.apache.org/viewcvs?rev=325889&view=rev
Log:
Convert some Jexl expressions to JXPath so that they work also when used without javascript-flow.
Modified:
cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml
Modified: cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml
URL: http://svn.apache.org/viewcvs/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml?rev=325889&r1=325888&r2=325889&view=diff
==============================================================================
--- cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml (original)
+++ cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml Mon Oct 17 06:24:48 2005
@@ -87,7 +87,7 @@
<jx:if test="${cformsHelper.pushRepeater(id, false)}">
<jx:set var="repeater" value="${cformsHelper.peekWidget()}"/>
<jx:forEach varStatus="repeaterLoop" begin="0" end="${repeater.getSize() - 1}">
- <jx:if test="${cformsHelper.pushContainer(java.lang.Integer.toString(repeaterLoop.index))}">
+ <jx:if test="#{pushContainer($cformsHelper, java.lang.Integer.toString($repeaterLoop/index))}">
<jx:set var="widget" value="${cformsHelper.peekWidget()}"/>
<jx:evalBody/>
<jx:set var="cformsDummy" value="${cformsHelper.popWidget()}"/>
@@ -221,7 +221,7 @@
<jx:macro name="repeater-rows" targetNamespace="http://apache.org/cocoon/forms/1.0#template">
<jx:forEach varStatus="repeaterLoop" begin="0" end="${repeater.getSize() - 1}">
- <jx:if test="${cformsHelper.pushContainer(java.lang.Integer.toString(repeaterLoop.index))}">
+ <jx:if test="#{pushContainer($cformsHelper, java.lang.Integer.toString($repeaterLoop/index))}">
<jx:set var="widget" value="${cformsHelper.peekWidget()}"/>
<jx:evalBody/>
<jx:set var="cformsDummy" value="${cformsHelper.popWidget()}"/>
Re: JavaScript expressions in JXTG (was Re: svn commit: r325889)
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Sylvain Wallez wrote:
> Leszek Gawron wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Actually, I'm more and more annoyed by Jexl: JXTemplate is the *only*
>>> place in Cocoon where Jexl is used, and I would love to see it
>>> replaced by JavaScript expressions. Script/expression language
>>> consistency throughout Cocoon...
>>
>> hmmm... we have touched the subject once. At the time you have pointed
>> me with some javascript helper class to get the basics of rhino but I
>> lost that message. Do you happen to remember what class it was?
>>
>> This shouldn't be 'that' hard.
>
>
> Oh no, damn easy! See JavaScriptHelper in CForms.
Hmm.. looking at JavaScriptHelper I see you broke it again :)
> Index: C:/dev/apache-projects/cocoon-2.2.x/src/blocks/forms/trunk/java/org/apache/cocoon/forms/util/JavaScriptHelper.java
> ===================================================================
> --- C:/dev/apache-projects/cocoon-2.2.x/src/blocks/forms/trunk/java/org/apache/cocoon/forms/util/JavaScriptHelper.java (revision 289537)
> +++ C:/dev/apache-projects/cocoon-2.2.x/src/blocks/forms/trunk/java/org/apache/cocoon/forms/util/JavaScriptHelper.java (revision 289538)
> @@ -23,7 +23,6 @@
> import org.apache.avalon.framework.CascadingRuntimeException;
> import org.apache.cocoon.components.flow.FlowHelper;
> import org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptFlowHelper;
> -import org.apache.cocoon.environment.TemplateObjectModelHelper;
> import org.mozilla.javascript.Context;
> import org.mozilla.javascript.Function;
> import org.mozilla.javascript.JavaScriptException;
> @@ -39,7 +38,13 @@
> * @version $Id$
> */
> public class JavaScriptHelper {
> +
> /**
> + * A shared root scope, avoiding to recreate a new one each time.
> + */
> + private static Scriptable _rootScope = null;
> +
> + /**
> * Build a script with the content of a DOM element.
> *
> * @param element the element containing the script
> @@ -111,7 +116,20 @@
> * @return an appropriate root scope
> */
> public static Scriptable getRootScope() {
> - return TemplateObjectModelHelper.getScope();
> + // FIXME: TemplateOMH should be used in 2.2
> + //return TemplateObjectModelHelper.getScope();
> +
> +
> + if (_rootScope == null) {
> + // Create it if never used up to now
> + Context ctx = Context.enter();
> + try {
> + _rootScope = ctx.initStandardObjects(null);
> + } finally {
> + Context.exit();
> + }
> + }
> + return _rootScope;
> }
>
> /**
this is the former logic of JavaScriptHelper which is invalid because of
the fact that _rootScope is not thread safe. Please have look at how
TemplateOMH does it:
public static Scriptable getScope() {
Context ctx = Context.enter();
try {
// Create it if never used up to now
if (rootScope == null)
rootScope = ctx.initStandardObjects(null);
Scriptable scope = ctx.newObject(rootScope);
scope.setPrototype(rootScope);
scope.setParentScope(null);
return scope;
} finally {
Context.exit();
}
}
(shouldn't we wrap this code with synchronized block?)
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: JavaScript expressions in JXTG (was Re: svn commit: r325889)
- want it ? GOT IT
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
Re: JavaScript expressions in JXTG (was Re: svn commit: r325889) - want it ? GOT IT
Posted by Rob Berens <rb...@osirion.nl>.
----- Original Message -----
From: "Leszek Gawron" <lg...@mobilebox.pl>
To: <de...@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: rberens@osirion.nl
Re: JavaScript expressions in JXTG (was Re: svn commit: r325889)
- want it ? GOT IT
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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.
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: JavaScript expressions in JXTG (was Re: svn commit: r325889)
- want it ? GOT IT
Posted by Sylvain Wallez <sy...@apache.org>.
Leszek Gawron wrote:
> Sylvain Wallez wrote:
>>> 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.
>>
>> Hehe, good idea :-) Let's keep it just besides JXTG while we slowly
>> migrate to CTemplate.
>>
>> BTW, I haven't used that one yet, but prefer muuuch more prefixing
>> expressions inside the {} with the language name rather than having
>> to run out of special characters to place in front of {. We have, $,
>> # and now @, what's next :-)
> @{} has been only for you to test it. :)
Ah, ok! Many thanks :-)
Now this week is dedicated to fixes and cleanup for 2.1.8, so I won't
try it before next week...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: JavaScript expressions in JXTG (was Re: svn commit: r325889)
- want it ? GOT IT
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Sylvain Wallez 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.
>>
>> If we move them to core we could also start to use the expression
>> abstraction in the rest of 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?
>
>
> Do you mean 2.2 core? Then yes. If it's 2.1.8 core, then let's wait
> after the release to promote the template block in the 2.1 branch.
>
>> 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.
>
>
> Hehe, good idea :-) Let's keep it just besides JXTG while we slowly
> migrate to CTemplate.
>
> BTW, I haven't used that one yet, but prefer muuuch more prefixing
> expressions inside the {} with the language name rather than having to
> run out of special characters to place in front of {. We have, $, # and
> now @, what's next :-)
@{} has been only for you to test it. :)
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: JavaScript expressions in JXTG (was Re: svn commit: r325889)
- want it ? GOT IT
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Sylvain Wallez wrote:
> Daniel Fagerstrom wrote:
...
>> If we move them to core we could also start to use the expression
>> abstraction in the rest of 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?
>
>
> Do you mean 2.2 core?
Of course, I only talk about 2.2.
> Then yes. If it's 2.1.8 core, then let's wait after the release to
> promote the template block in the 2.1 branch.
Sure.
...
/Daniel
Re: JavaScript expressions in JXTG (was Re: svn commit: r325889)
- want it ? GOT IT
Posted by Sylvain Wallez <sy...@apache.org>.
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.
>
> If we move them to core we could also start to use the expression
> abstraction in the rest of 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?
Do you mean 2.2 core? Then yes. If it's 2.1.8 core, then let's wait
after the release to promote the template block in the 2.1 branch.
> 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.
Hehe, good idea :-) Let's keep it just besides JXTG while we slowly
migrate to CTemplate.
BTW, I haven't used that one yet, but prefer muuuch more prefixing
expressions inside the {} with the language name rather than having to
run out of special characters to place in front of {. We have, $, # and
now @, what's next :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: JavaScript expressions in JXTG (was Re: svn commit: r325889)
- want it ? GOT IT
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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.
If we move them to core we could also start to use the expression
abstraction in the rest of 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.
WDYT?
/Daniel
Re: JavaScript expressions in JXTG (was Re: svn commit: r325889)
- want it ? GOT IT
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Sylvain Wallez wrote:
> Leszek Gawron wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Actually, I'm more and more annoyed by Jexl: JXTemplate is the *only*
>>> place in Cocoon where Jexl is used, and I would love to see it
>>> replaced by JavaScript expressions. Script/expression language
>>> consistency throughout Cocoon...
>>
>> hmmm... we have touched the subject once. At the time you have pointed
>> me with some javascript helper class to get the basics of rhino but I
>> lost that message. Do you happen to remember what class it was?
>>
>> This shouldn't be 'that' hard.
>
>
> Oh no, damn easy! See JavaScriptHelper in CForms.
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)
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: JavaScript expressions in JXTG (was Re: svn commit: r325889)
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Sylvain Wallez wrote:
> Leszek Gawron wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Actually, I'm more and more annoyed by Jexl: JXTemplate is the *only*
>>> place in Cocoon where Jexl is used, and I would love to see it
>>> replaced by JavaScript expressions. Script/expression language
>>> consistency throughout Cocoon...
>>
>> hmmm... we have touched the subject once. At the time you have pointed
>> me with some javascript helper class to get the basics of rhino but I
>> lost that message. Do you happen to remember what class it was?
>>
>> This shouldn't be 'that' hard.
>
>
> Oh no, damn easy! See JavaScriptHelper in CForms.
>
> But the problem is elsewhere: what syntax will we use for JS expression
> in JXTG. I would love to have it replace Jexl in "${}" expressions but
> it ain't that easy as it will break all existing templates.
>
> We should have a configuration in the new JXTG that associates prefixes
> of the "{" character to languages.
doh! that's already implemented in CTemplate:
<jx:out value="{jexl:expression}"/>
<jx:out value="{jxpath:expression}/>
<jx:out value="{default:expression}"/>
no more ${} and #{}. For default template language (you choose one in
cocoon.xconf) that's as compact as you cant get : {expression}
so {js:expression} is just a matter of implementing a few interfaces.
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
JavaScript expressions in JXTG (was Re: svn commit: r325889)
Posted by Sylvain Wallez <sy...@apache.org>.
Leszek Gawron wrote:
> Sylvain Wallez wrote:
>> Actually, I'm more and more annoyed by Jexl: JXTemplate is the *only*
>> place in Cocoon where Jexl is used, and I would love to see it
>> replaced by JavaScript expressions. Script/expression language
>> consistency throughout Cocoon...
> hmmm... we have touched the subject once. At the time you have pointed
> me with some javascript helper class to get the basics of rhino but I
> lost that message. Do you happen to remember what class it was?
>
> This shouldn't be 'that' hard.
Oh no, damn easy! See JavaScriptHelper in CForms.
But the problem is elsewhere: what syntax will we use for JS expression
in JXTG. I would love to have it replace Jexl in "${}" expressions but
it ain't that easy as it will break all existing templates.
We should have a configuration in the new JXTG that associates prefixes
of the "{" character to languages.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: svn commit: r325889 - /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Sylvain Wallez wrote:
> Actually, I'm more and more annoyed by Jexl: JXTemplate is the *only*
> place in Cocoon where Jexl is used, and I would love to see it replaced
> by JavaScript expressions. Script/expression language consistency
> throughout Cocoon...
hmmm... we have touched the subject once. At the time you have pointed
me with some javascript helper class to get the basics of rhino but I
lost that message. Do you happen to remember what class it was?
This shouldn't be 'that' hard.
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: svn commit: r325889 - /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Sylvain Wallez wrote:
...
> Actually, I'm more and more annoyed by Jexl: JXTemplate is the *only*
> place in Cocoon where Jexl is used, and I would love to see it
> replaced by JavaScript expressions. Script/expression language
> consistency throughout Cocoon...
It is not that hard, just add an Rhino implementation of the
o.a.c.components.expression interfaces in template. Inspiration can be
found in
http://svn.apache.org/viewcvs.cgi/jakarta/commons/dormant/jex/trunk/src/java/org/apache/commons/jex/javascript/.
From the dead project jex that the expression abstraction in template
was inspired of.
/Daniel
Re: svn commit: r325889 - /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml
Posted by Sylvain Wallez <sy...@apache.org>.
Bruno Dumon wrote:
> On Mon, 2005-10-17 at 16:50 +0200, Leszek Gawron wrote:
>
>> bruno@apache.org wrote:
>>
>>> Author: bruno
>>> Date: Mon Oct 17 06:24:48 2005
>>> New Revision: 325889
>>>
>>> URL: http://svn.apache.org/viewcvs?rev=325889&view=rev
>>> Log:
>>> Convert some Jexl expressions to JXPath so that they work also when used without javascript-flow.
>>>
>>> Modified:
>>> cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml
>>>
>>> Modified: cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml
>>> URL: http://svn.apache.org/viewcvs/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml?rev=325889&r1=325888&r2=325889&view=diff
>>> ==============================================================================
>>> --- cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml (original)
>>> +++ cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml Mon Oct 17 06:24:48 2005
>>> @@ -87,7 +87,7 @@
>>> <jx:if test="${cformsHelper.pushRepeater(id, false)}">
>>> <jx:set var="repeater" value="${cformsHelper.peekWidget()}"/>
>>> <jx:forEach varStatus="repeaterLoop" begin="0" end="${repeater.getSize() - 1}">
>>> - <jx:if test="${cformsHelper.pushContainer(java.lang.Integer.toString(repeaterLoop.index))}">
>>> + <jx:if test="#{pushContainer($cformsHelper, java.lang.Integer.toString($repeaterLoop/index))}">
>>>
>> I do not get it: why do you think this change is necessary? Does it
>> break when used with JEXL ?
>>
>
> It breaks when the template is not executed via a sendPage call from
> rhino flowscript (e.g. from an apple, or a directly called pipeline).
>
> This is because jexl in itself does not allow to call static methods
> like java.lang.Integer.toString. The "java" is a special variable
> inserted into the jexl context by the jx template generator, and is only
> available when called from flow (since it is a rhino object). It would
> be possible to make something equivalent for when not using rhino, but
> the above is a quicker solution.
>
Weird...
Actually, I'm more and more annoyed by Jexl: JXTemplate is the *only*
place in Cocoon where Jexl is used, and I would love to see it replaced
by JavaScript expressions. Script/expression language consistency
throughout Cocoon...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: svn commit: r325889
- /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml
Posted by Bruno Dumon <br...@outerthought.org>.
On Mon, 2005-10-17 at 17:33 +0200, Leszek Gawron wrote:
> Bruno Dumon wrote:
> > On Mon, 2005-10-17 at 16:50 +0200, Leszek Gawron wrote:
> >
> >>bruno@apache.org wrote:
> >>
> >>>Author: bruno
> >>>Date: Mon Oct 17 06:24:48 2005
> >>>New Revision: 325889
> >>>
> >>>URL: http://svn.apache.org/viewcvs?rev=325889&view=rev
> >>>Log:
> >>>Convert some Jexl expressions to JXPath so that they work also when used without javascript-flow.
> >>>
> >>>Modified:
> >>> cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml
> >>>
> >>>Modified: cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml
> >>>URL: http://svn.apache.org/viewcvs/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml?rev=325889&r1=325888&r2=325889&view=diff
> >>>==============================================================================
> >>>--- cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml (original)
> >>>+++ cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml Mon Oct 17 06:24:48 2005
> >>>@@ -87,7 +87,7 @@
> >>> <jx:if test="${cformsHelper.pushRepeater(id, false)}">
> >>> <jx:set var="repeater" value="${cformsHelper.peekWidget()}"/>
> >>> <jx:forEach varStatus="repeaterLoop" begin="0" end="${repeater.getSize() - 1}">
> >>>- <jx:if test="${cformsHelper.pushContainer(java.lang.Integer.toString(repeaterLoop.index))}">
> >>>+ <jx:if test="#{pushContainer($cformsHelper, java.lang.Integer.toString($repeaterLoop/index))}">
> >>
> >>I do not get it: why do you think this change is necessary? Does it
> >>break when used with JEXL ?
> >
> >
> > It breaks when the template is not executed via a sendPage call from
> > rhino flowscript (e.g. from an apple, or a directly called pipeline).
> >
> > This is because jexl in itself does not allow to call static methods
> > like java.lang.Integer.toString. The "java" is a special variable
> > inserted into the jexl context by the jx template generator, and is only
> > available when called from flow (since it is a rhino object). It would
> > be possible to make something equivalent for when not using rhino, but
> > the above is a quicker solution.
> you are right but you are wrong :) You are right Jexl alone does not
> support java.* syntax. Still even if not used from flow we enrich object
> model with following data (TemplateObjectModelHelper.java):
>
> > /**
> > * Add java packages to object model. Allows to construct java objects.
> > * @param objectModel usually the result of invoking getTemplateObjectModel
> > */
> > public static Object addJavaPackages( Map objectModel ) {
> > Object javaPkg = FOM_JavaScriptFlowHelper.getJavaPackage(objectModel);
> > Object pkgs = FOM_JavaScriptFlowHelper.getPackages(objectModel);
> >
> > // packages might have already been set up if flowscript is being used
> > if ( javaPkg != null && pkgs != null ) {
> > objectModel.put( "Packages", javaPkg );
> > objectModel.put( "java", pkgs );
> > } else {
> > Context cx = Context.enter();
> > try {
> > final String JAVA_PACKAGE = "JavaPackage";
> > ClassLoader cl = Thread.currentThread().getContextClassLoader();
> > Scriptable newPackages = new NativeJavaPackage( "", cl );
> > newPackages.setParentScope( getScope() );
> > newPackages.setPrototype( ScriptableObject.getClassPrototype( getScope(),
> > JAVA_PACKAGE ) );
> > objectModel.put( "Packages", newPackages );
> > objectModel.put( "java", ScriptableObject.getProperty( getScope(), "java" ) );
> > } finally {
> > Context.exit();
> > }
> > }
> > return objectModel;
> > }
>
> You should see no difference when using JEXL from flow or without one.
> If I am wrong - this is clearly a bug.
Ah, I'm using Cocoon 2.1.x, I assume the above is from the new template
block.
I actually considered for a moment to add something like that, but
wasn't sure about introducing a rhino dependency into the
JXTemplateGenerator. Maybe I'll look into adding the above to the "old"
JXTemplateGenerator too.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: svn commit: r325889 - /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Bruno Dumon wrote:
> On Mon, 2005-10-17 at 16:50 +0200, Leszek Gawron wrote:
>
>>bruno@apache.org wrote:
>>
>>>Author: bruno
>>>Date: Mon Oct 17 06:24:48 2005
>>>New Revision: 325889
>>>
>>>URL: http://svn.apache.org/viewcvs?rev=325889&view=rev
>>>Log:
>>>Convert some Jexl expressions to JXPath so that they work also when used without javascript-flow.
>>>
>>>Modified:
>>> cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml
>>>
>>>Modified: cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml
>>>URL: http://svn.apache.org/viewcvs/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml?rev=325889&r1=325888&r2=325889&view=diff
>>>==============================================================================
>>>--- cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml (original)
>>>+++ cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml Mon Oct 17 06:24:48 2005
>>>@@ -87,7 +87,7 @@
>>> <jx:if test="${cformsHelper.pushRepeater(id, false)}">
>>> <jx:set var="repeater" value="${cformsHelper.peekWidget()}"/>
>>> <jx:forEach varStatus="repeaterLoop" begin="0" end="${repeater.getSize() - 1}">
>>>- <jx:if test="${cformsHelper.pushContainer(java.lang.Integer.toString(repeaterLoop.index))}">
>>>+ <jx:if test="#{pushContainer($cformsHelper, java.lang.Integer.toString($repeaterLoop/index))}">
>>
>>I do not get it: why do you think this change is necessary? Does it
>>break when used with JEXL ?
>
>
> It breaks when the template is not executed via a sendPage call from
> rhino flowscript (e.g. from an apple, or a directly called pipeline).
>
> This is because jexl in itself does not allow to call static methods
> like java.lang.Integer.toString. The "java" is a special variable
> inserted into the jexl context by the jx template generator, and is only
> available when called from flow (since it is a rhino object). It would
> be possible to make something equivalent for when not using rhino, but
> the above is a quicker solution.
you are right but you are wrong :) You are right Jexl alone does not
support java.* syntax. Still even if not used from flow we enrich object
model with following data (TemplateObjectModelHelper.java):
> /**
> * Add java packages to object model. Allows to construct java objects.
> * @param objectModel usually the result of invoking getTemplateObjectModel
> */
> public static Object addJavaPackages( Map objectModel ) {
> Object javaPkg = FOM_JavaScriptFlowHelper.getJavaPackage(objectModel);
> Object pkgs = FOM_JavaScriptFlowHelper.getPackages(objectModel);
>
> // packages might have already been set up if flowscript is being used
> if ( javaPkg != null && pkgs != null ) {
> objectModel.put( "Packages", javaPkg );
> objectModel.put( "java", pkgs );
> } else {
> Context cx = Context.enter();
> try {
> final String JAVA_PACKAGE = "JavaPackage";
> ClassLoader cl = Thread.currentThread().getContextClassLoader();
> Scriptable newPackages = new NativeJavaPackage( "", cl );
> newPackages.setParentScope( getScope() );
> newPackages.setPrototype( ScriptableObject.getClassPrototype( getScope(),
> JAVA_PACKAGE ) );
> objectModel.put( "Packages", newPackages );
> objectModel.put( "java", ScriptableObject.getProperty( getScope(), "java" ) );
> } finally {
> Context.exit();
> }
> }
> return objectModel;
> }
You should see no difference when using JEXL from flow or without one.
If I am wrong - this is clearly a bug.
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: svn commit: r325889 -
/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml
Posted by Bruno Dumon <br...@outerthought.org>.
On Mon, 2005-10-17 at 16:50 +0200, Leszek Gawron wrote:
> bruno@apache.org wrote:
> > Author: bruno
> > Date: Mon Oct 17 06:24:48 2005
> > New Revision: 325889
> >
> > URL: http://svn.apache.org/viewcvs?rev=325889&view=rev
> > Log:
> > Convert some Jexl expressions to JXPath so that they work also when used without javascript-flow.
> >
> > Modified:
> > cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml
> >
> > Modified: cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml
> > URL: http://svn.apache.org/viewcvs/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml?rev=325889&r1=325888&r2=325889&view=diff
> > ==============================================================================
> > --- cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml (original)
> > +++ cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml Mon Oct 17 06:24:48 2005
> > @@ -87,7 +87,7 @@
> > <jx:if test="${cformsHelper.pushRepeater(id, false)}">
> > <jx:set var="repeater" value="${cformsHelper.peekWidget()}"/>
> > <jx:forEach varStatus="repeaterLoop" begin="0" end="${repeater.getSize() - 1}">
> > - <jx:if test="${cformsHelper.pushContainer(java.lang.Integer.toString(repeaterLoop.index))}">
> > + <jx:if test="#{pushContainer($cformsHelper, java.lang.Integer.toString($repeaterLoop/index))}">
> I do not get it: why do you think this change is necessary? Does it
> break when used with JEXL ?
It breaks when the template is not executed via a sendPage call from
rhino flowscript (e.g. from an apple, or a directly called pipeline).
This is because jexl in itself does not allow to call static methods
like java.lang.Integer.toString. The "java" is a special variable
inserted into the jexl context by the jx template generator, and is only
available when called from flow (since it is a rhino object). It would
be possible to make something equivalent for when not using rhino, but
the above is a quicker solution.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: svn commit: r325889 - /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml
Posted by Leszek Gawron <lg...@mobilebox.pl>.
bruno@apache.org wrote:
> Author: bruno
> Date: Mon Oct 17 06:24:48 2005
> New Revision: 325889
>
> URL: http://svn.apache.org/viewcvs?rev=325889&view=rev
> Log:
> Convert some Jexl expressions to JXPath so that they work also when used without javascript-flow.
>
> Modified:
> cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml
>
> Modified: cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml
> URL: http://svn.apache.org/viewcvs/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml?rev=325889&r1=325888&r2=325889&view=diff
> ==============================================================================
> --- cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml (original)
> +++ cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/jx-macros.xml Mon Oct 17 06:24:48 2005
> @@ -87,7 +87,7 @@
> <jx:if test="${cformsHelper.pushRepeater(id, false)}">
> <jx:set var="repeater" value="${cformsHelper.peekWidget()}"/>
> <jx:forEach varStatus="repeaterLoop" begin="0" end="${repeater.getSize() - 1}">
> - <jx:if test="${cformsHelper.pushContainer(java.lang.Integer.toString(repeaterLoop.index))}">
> + <jx:if test="#{pushContainer($cformsHelper, java.lang.Integer.toString($repeaterLoop/index))}">
I do not get it: why do you think this change is necessary? Does it
break when used with JEXL ?
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65