You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henrib <hb...@gmail.com> on 2009/08/12 16:29:43 UTC
[JEXL] functional directions
I was implementing local variables & functions support when I realized it'd
be best to ask the community what they seek in JEXL before crossing this
boundary.
I've been using JEXL 1.1 as an "expression language" (like the JSP/JSF one),
a tiny syntax that would only evaluate simple expressions; the if, loop
constructs and blocks -{...}- are already "too much" in this view. In
JSPs/taglibs, all these are handled through "XML" syntaxes - if you allow me
this shortcut.
Going towards a "scripting language" seems to be our current direction (the
previously cited syntactic elements, JSR-233 support, main methods). At the
current rate if this is any indication, the 'jar' size will be 50% bigger
than 1.1 soon and JEXL will indeed become a scripting language close(r) to
JavaScript/ECMAScript & friends.
So, just as a sanity check and to ensure the choice is explicit, should JEXL
"restrict" itself to a simple EL or "augment" itself towards a (simplified)
ECMAscript ? In the former case, it {c,sh}ould mean removing every syntax
that can use a block (loops, if, etc.); in the latter, we'll probably need
local variables, functions & return, loop enhancements (continue, break).
That's provocative but you get the idea. :-)
Are there functional needs that you expect JEXL to cover ? Are there
constraints that would make any other scripting language - on the JVM - non
usable (complexity, size, ...)?
Thanks for sharing your thoughts,
Henrib
--
View this message in context: http://www.nabble.com/-JEXL--functional-directions-tp24937743p24937743.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JEXL] functional directions
Posted by Henrib <hb...@gmail.com>.
Ralph Goers wrote:
>
> I have found Jexl to be valuable for processing expressions. However,
> I haven't come across the need for another scripting language.
> Typically, I've used Jexl in programs where I want to allow
> complicated expressions with some sort of configuration such as in
> Cocoon's sitemap or in commons configuration. If Jexl is going to
> support scripting is it possible to split that into a separate jar?
>
> Ralph
>
>
Thanks for the feedback Ralph.
Just for clarity, JEXL will continue to be usable as an EL; scripting
capabilities come on top of those.
One of the possible usage for more scripting capabilities - when used in XML
based situations - would be to generate/execute scripts instead of
"interpreting" nodes (Jelly like?). And/or an easier integration glue
between declarative (XML) and procedural (Java) worlds; iterate over nodes
in the script, create objects based on EL attributes & store them in Java
objects.
As for separate jars, I dont know; what would be the motivation?
I can see jar size but we are talking 144Kb (jexl-1.1) versus 198Kb
(jexl-2.0 trunk as is); a reduced grammar might shove say 20/30Kb and a
fuller one would add about the same. Not sure that's enough of a difference.
And the technical hurdle of splitting the javacc grammar and still have the
"EL" as a sub-part of the "Script" would most likely mean have the full
syntax in EL but generate "parsing" errors when used (that's way easier than
2 jjt files with one dependant upon the other...).
--
View this message in context: http://www.nabble.com/-JEXL--functional-directions-tp24937743p24943436.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JEXL] functional directions
Posted by Ralph Goers <ra...@dslextreme.com>.
I have found Jexl to be valuable for processing expressions. However,
I haven't come across the need for another scripting language.
Typically, I've used Jexl in programs where I want to allow
complicated expressions with some sort of configuration such as in
Cocoon's sitemap or in commons configuration. If Jexl is going to
support scripting is it possible to split that into a separate jar?
Ralph
On Aug 12, 2009, at 7:29 AM, Henrib wrote:
>
> I was implementing local variables & functions support when I
> realized it'd
> be best to ask the community what they seek in JEXL before crossing
> this
> boundary.
>
> I've been using JEXL 1.1 as an "expression language" (like the JSP/
> JSF one),
> a tiny syntax that would only evaluate simple expressions; the if,
> loop
> constructs and blocks -{...}- are already "too much" in this view. In
> JSPs/taglibs, all these are handled through "XML" syntaxes - if you
> allow me
> this shortcut.
>
> Going towards a "scripting language" seems to be our current
> direction (the
> previously cited syntactic elements, JSR-233 support, main methods).
> At the
> current rate if this is any indication, the 'jar' size will be 50%
> bigger
> than 1.1 soon and JEXL will indeed become a scripting language
> close(r) to
> JavaScript/ECMAScript & friends.
>
> So, just as a sanity check and to ensure the choice is explicit,
> should JEXL
> "restrict" itself to a simple EL or "augment" itself towards a
> (simplified)
> ECMAscript ? In the former case, it {c,sh}ould mean removing every
> syntax
> that can use a block (loops, if, etc.); in the latter, we'll
> probably need
> local variables, functions & return, loop enhancements (continue,
> break).
> That's provocative but you get the idea. :-)
>
> Are there functional needs that you expect JEXL to cover ? Are there
> constraints that would make any other scripting language - on the
> JVM - non
> usable (complexity, size, ...)?
> Thanks for sharing your thoughts,
> Henrib
> --
> View this message in context: http://www.nabble.com/-JEXL--functional-directions-tp24937743p24937743.html
> Sent from the Commons - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JEXL] functional directions
Posted by Rahul Akolkar <ra...@gmail.com>.
On Fri, Aug 14, 2009 at 9:50 AM, Henrib<hb...@gmail.com> wrote:
>
>
>
> Rahul Akolkar wrote:
>>
>> In my mind, its the tradeoff between three additional smallish classes
>> and the complexity of adding a new build artifact -- if you want to
>> look at adding an m2 module for the 223 bits, that'd be fine with me.
>>
> As long as it does not imply we expect JEXL to become more than an EL - aka
> become another "full-fledge" scripting engine, there is no further potential
> argument. I just felt it was better to state the project direction than let
> it be subject to interpretation; JEXL is geared at excelling as an EL
> language - period.
>
<snip/>
Understood, thanks for starting this discussion about project direction.
>
> Rahul Akolkar wrote:
>>
>> Yeah, OTOH, theres something to be said about having it in the jar
>> (specifically, ease of access).
>> ...
>> While we're at it, I see little value in the junit package.
>>
> I get it; as long as the community agrees upon it and this is only
> convenience and nothing more - nor further-, all my previous remarks are
> moot points. I just felt the need for a clear and unambiguous direction to
> emerge.
>
<snap/>
OK.
>
> Besides, +1 in moving the junit package.
<snip/>
I've created JEXL-84 for 2.0 as there seems to be consensus on this:
https://issues.apache.org/jira/browse/JEXL-84
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JEXL] functional directions
Posted by Henrib <hb...@gmail.com>.
Rahul Akolkar wrote:
>
> In my mind, its the tradeoff between three additional smallish classes
> and the complexity of adding a new build artifact -- if you want to
> look at adding an m2 module for the 223 bits, that'd be fine with me.
>
As long as it does not imply we expect JEXL to become more than an EL - aka
become another "full-fledge" scripting engine, there is no further potential
argument. I just felt it was better to state the project direction than let
it be subject to interpretation; JEXL is geared at excelling as an EL
language - period.
Rahul Akolkar wrote:
>
> Yeah, OTOH, theres something to be said about having it in the jar
> (specifically, ease of access).
> ...
> While we're at it, I see little value in the junit package.
>
I get it; as long as the community agrees upon it and this is only
convenience and nothing more - nor further-, all my previous remarks are
moot points. I just felt the need for a clear and unambiguous direction to
emerge.
Besides, +1 in moving the junit package.
--
View this message in context: http://www.nabble.com/-JEXL--functional-directions-tp24937743p24972053.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JEXL] functional directions
Posted by sebb <se...@gmail.com>.
On 13/08/2009, Rahul Akolkar <ra...@gmail.com> wrote:
> On Thu, Aug 13, 2009 at 7:12 AM, Henrib<hb...@gmail.com> wrote:
> <snip/>
>
> >
> >
> > Rahul Akolkar wrote:
> >>
> >> Not really a direction per se:
> >> * We've had some syntactic additions, but its been organic growth
> >> * We do have a JSR-223 engine for convenience, I think we shouldn't
> >> go too far with it (no jexl.conf à la JEXL-63 please)
> >> * Same with Main classes, good for playing around but important to keep
> >> simple
> >>
> >> No coincidence that my latest comment on JEXL-70 contains "The purpose
> >> of Commons JEXL is to build JEXL, not complex command-line classes to
> >> use JEXL" (and by way of extension, other such peripheral bits).
> >>
> >
> > Ok... sort of. I've yet to understand the inclusion of jsr-223 support
> > (Scripting language for the java platform) within JEXL; an external
> > "jexl-script.jar" that implements the factory & the main method would have
> > made the convenience part clearer.
>
> <snap/>
>
> In my mind, its the tradeoff between three additional smallish classes
> and the complexity of adding a new build artifact -- if you want to
> look at adding an m2 module for the 223 bits, that'd be fine with me.
>
A separate jar also makes it more tedious to use JEXL as a JSR-223
scripting language.
That was one of the main reasons for including the code in JEXL 2.0,
rather than in BSF 3.0 or elsewhere.
>
> > Imho, the main method in JEXL itself should be a test class in the test
> > package.
>
>
> Yeah, OTOH, theres something to be said about having it in the jar
> (specifically, ease of access). So, this one's for you and sebb to
> discuss :-)
Yes, that's why I put them in the main code jar not the test tree.
Can't see any point otherwise, as the test classes are not shipped.
> While we're at it, I see little value in the junit package.
+1
Seems to me that might be better in the test code.
> -Rahul
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JEXL] functional directions
Posted by Rahul Akolkar <ra...@gmail.com>.
On Thu, Aug 13, 2009 at 7:12 AM, Henrib<hb...@gmail.com> wrote:
<snip/>
>
>
> Rahul Akolkar wrote:
>>
>> Not really a direction per se:
>> * We've had some syntactic additions, but its been organic growth
>> * We do have a JSR-223 engine for convenience, I think we shouldn't
>> go too far with it (no jexl.conf à la JEXL-63 please)
>> * Same with Main classes, good for playing around but important to keep
>> simple
>>
>> No coincidence that my latest comment on JEXL-70 contains "The purpose
>> of Commons JEXL is to build JEXL, not complex command-line classes to
>> use JEXL" (and by way of extension, other such peripheral bits).
>>
>
> Ok... sort of. I've yet to understand the inclusion of jsr-223 support
> (Scripting language for the java platform) within JEXL; an external
> "jexl-script.jar" that implements the factory & the main method would have
> made the convenience part clearer.
<snap/>
In my mind, its the tradeoff between three additional smallish classes
and the complexity of adding a new build artifact -- if you want to
look at adding an m2 module for the 223 bits, that'd be fine with me.
> Imho, the main method in JEXL itself should be a test class in the test
> package.
Yeah, OTOH, theres something to be said about having it in the jar
(specifically, ease of access). So, this one's for you and sebb to
discuss :-)
While we're at it, I see little value in the junit package.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JEXL] functional directions
Posted by Henrib <hb...@gmail.com>.
Thanks for being crystal clear. :-)
--
View this message in context: http://www.nabble.com/-JEXL--functional-directions-tp24937743p24953662.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JEXL] functional directions
Posted by Henrib <hb...@gmail.com>.
Rahul Akolkar wrote:
>
> I say we keep it simple ...
>
Fine with me.
Rahul Akolkar wrote:
>
> Using that comparison, the place where JEXL excelled was to fill the
> gap that JSP EL had in terms of assignments, method invocations and a
> generally more seamless bridging to Java objects in the expression
> language context. Surrounding procedural Java code took the place of
> the JSP taglib (XML, as you say above) syntax as and when needed.
>
Agreed; the UnifiedJEXL for text nodes & attributes is aiming at this goal
too.
Rahul Akolkar wrote:
>
> Not really a direction per se:
> * We've had some syntactic additions, but its been organic growth
> * We do have a JSR-223 engine for convenience, I think we shouldn't
> go too far with it (no jexl.conf à la JEXL-63 please)
> * Same with Main classes, good for playing around but important to keep
> simple
>
> No coincidence that my latest comment on JEXL-70 contains "The purpose
> of Commons JEXL is to build JEXL, not complex command-line classes to
> use JEXL" (and by way of extension, other such peripheral bits).
>
Ok... sort of. I've yet to understand the inclusion of jsr-223 support
(Scripting language for the java platform) within JEXL; an external
"jexl-script.jar" that implements the factory & the main method would have
made the convenience part clearer.
Imho, the main method in JEXL itself should be a test class in the test
package.
Rahul Akolkar wrote:
>
> I'm happy to keep things the way they are -- no more, no less for 2.0.
>
Thanks for betty crystal clear. :-)
--
View this message in context: http://www.nabble.com/-JEXL--functional-directions-tp24937743p24953043.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JEXL] functional directions
Posted by Rahul Akolkar <ra...@gmail.com>.
I say we keep it simple ...
On Wed, Aug 12, 2009 at 10:29 AM, Henrib<hb...@gmail.com> wrote:
>
> I was implementing local variables & functions support when I realized it'd
> be best to ask the community what they seek in JEXL before crossing this
> boundary.
>
<snip/>
Glad you asked :-)
> I've been using JEXL 1.1 as an "expression language" (like the JSP/JSF one),
> a tiny syntax that would only evaluate simple expressions; the if, loop
> constructs and blocks -{...}- are already "too much" in this view. In
> JSPs/taglibs, all these are handled through "XML" syntaxes - if you allow me
> this shortcut.
>
<snap/>
Using that comparison, the place where JEXL excelled was to fill the
gap that JSP EL had in terms of assignments, method invocations and a
generally more seamless bridging to Java objects in the expression
language context. Surrounding procedural Java code took the place of
the JSP taglib (XML, as you say above) syntax as and when needed.
> Going towards a "scripting language" seems to be our current direction (the
> previously cited syntactic elements, JSR-233 support, main methods). At the
> current rate if this is any indication, the 'jar' size will be 50% bigger
> than 1.1 soon and JEXL will indeed become a scripting language close(r) to
> JavaScript/ECMAScript & friends.
>
<snip/>
Not really a direction per se:
* We've had some syntactic additions, but its been organic growth
* We do have a JSR-223 engine for convenience, I think we shouldn't
go too far with it (no jexl.conf à la JEXL-63 please)
* Same with Main classes, good for playing around but important to keep simple
No coincidence that my latest comment on JEXL-70 contains "The purpose
of Commons JEXL is to build JEXL, not complex command-line classes to
use JEXL" (and by way of extension, other such peripheral bits).
> So, just as a sanity check and to ensure the choice is explicit, should JEXL
> "restrict" itself to a simple EL or "augment" itself towards a (simplified)
> ECMAscript ? In the former case, it {c,sh}ould mean removing every syntax
> that can use a block (loops, if, etc.); in the latter, we'll probably need
> local variables, functions & return, loop enhancements (continue, break).
> That's provocative but you get the idea. :-)
>
<snap/>
I'm happy to keep things the way they are -- no more, no less for 2.0.
-Rahul
> Are there functional needs that you expect JEXL to cover ? Are there
> constraints that would make any other scripting language - on the JVM - non
> usable (complexity, size, ...)?
> Thanks for sharing your thoughts,
> Henrib
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org