You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ingmar Kliche <in...@googlemail.com> on 2008/12/16 23:40:28 UTC

[SCXML] Shortcomings of JEXLContext

I tried to use the o.a.c.s JEXL Context/Evaluator with an implementation of
the <script> element. I want to make the <script> implemenation independent
of the expression languange. But unfortunately it seems to me that EL is not
useful (e.g. does not support assignments) and Jexl has some shortcomings:

1) I tried a script with multiple statements, like:

<script>
  x = y;
  y = 3;
</script>

While executing this script I get:

WARNUNG: The JEXL Expression created will be a reference to the first
expression from the supplied script: "
        x = y;
        y = 3;"

Does the JEXL implementation not support multiple statements per expression?

2) Unfortunately the o.a.c.s JexlEvaluator#eval() generates an
"effectiveContext" (to implement the scope chain) and passes it to the JEXL
expression for execution. Thus any modification taken by the script (like
any assingments as "x = y") will modify the "effectiveContext", not the
actual state context. After executing "x=y", "x" remains unchanged within
the states context.

Is the JexlContext implemenatation useful for a <script> implementation at
all from this perspective?

- Ingmar.

Re: [SCXML] Shortcomings of JEXLContext

Posted by Rahul Akolkar <ra...@gmail.com>.
I've added support for the SCXML Script Module to the J6 branch and
addressed the JEXLContext shortcomings (wasn't designed for scripts)
as discussed below.

Here are a couple of simple test case documents using inline scripts:

JEXL:  http://svn.apache.org/repos/asf/commons/proper/scxml/branches/J6/src/test/java/org/apache/commons/scxml/env/jexl/script-01.xml

JavaScript:  http://svn.apache.org/repos/asf/commons/proper/scxml/branches/J6/src/test/java/org/apache/commons/scxml/env/javascript/script-01.xml

-Rahul


On Tue, Dec 16, 2008 at 6:22 PM, Rahul Akolkar <ra...@gmail.com> wrote:
> As a reminder, Commons SCXML does not support the SCXML Script Module
> yet, since its not required (the required bits get more attention :-).
> However, thats mainly a matter of prioritization, so if such support
> becomes available it can surely be added.
>
> At the crux of the issue, there are two options:
> (1) The elegant way to add this support requires an additional method
> to the Evaluator interface (say, evalScript) and that breaks backward
> compatibility.
> (2) Alternatively, we can create an extended Evaluator interface that
> handles scripts (and then check whether the Evaluator implementation
> supports this extended interface at the point where scripts are
> executed -- or throw up in some reasonable fashion otherwise)
>
> Given we're in 0.x releases, (1) might still be OK and is definitely cleaner.
>
> To your questions ...
>
> On Tue, Dec 16, 2008 at 5:40 PM, Ingmar Kliche
> <in...@googlemail.com> wrote:
>> I tried to use the o.a.c.s JEXL Context/Evaluator with an implementation of
>> the <script> element. I want to make the <script> implemenation independent
>> of the expression languange. But unfortunately it seems to me that EL is not
>> useful (e.g. does not support assignments) and Jexl has some shortcomings:
>>
>> 1) I tried a script with multiple statements, like:
>>
>> <script>
>>  x = y;
>>  y = 3;
>> </script>
>>
>> While executing this script I get:
>>
>> WARNUNG: The JEXL Expression created will be a reference to the first
>> expression from the supplied script: "
>>        x = y;
>>        y = 3;"
>>
>> Does the JEXL implementation not support multiple statements per expression?
>>
> <snip/>
>
> It does, but you have to use the ScriptFactory (as against using
> ExpressionFactory) -- ties into comment above regarding a new
> Evaluator#evalScript() method.
>
>
>> 2) Unfortunately the o.a.c.s JexlEvaluator#eval() generates an
>> "effectiveContext" (to implement the scope chain) and passes it to the JEXL
>> expression for execution. Thus any modification taken by the script (like
>> any assingments as "x = y") will modify the "effectiveContext", not the
>> actual state context. After executing "x=y", "x" remains unchanged within
>> the states context.
>>
>> Is the JexlContext implemenatation useful for a <script> implementation at
>> all from this perspective?
>>
> <snap/>
>
> Correct, the out of the box implementation isn't conducive to scripts
> (writes aren't supported since those are handled via <assign>, for
> example). When we make the other changes to accomodate <script>, we
> will have to address this.
>
> Interim, it should be possible to implement script as a custom action
> (which is probably what you're doing here) and use your own evaluator
> implementation (similar to the extended one mentioned above) which the
> custom action leverages.
>
> -Rahul
>
>
>> - Ingmar.
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [SCXML] Shortcomings of JEXLContext

Posted by Rahul Akolkar <ra...@gmail.com>.
As a reminder, Commons SCXML does not support the SCXML Script Module
yet, since its not required (the required bits get more attention :-).
However, thats mainly a matter of prioritization, so if such support
becomes available it can surely be added.

At the crux of the issue, there are two options:
(1) The elegant way to add this support requires an additional method
to the Evaluator interface (say, evalScript) and that breaks backward
compatibility.
(2) Alternatively, we can create an extended Evaluator interface that
handles scripts (and then check whether the Evaluator implementation
supports this extended interface at the point where scripts are
executed -- or throw up in some reasonable fashion otherwise)

Given we're in 0.x releases, (1) might still be OK and is definitely cleaner.

To your questions ...

On Tue, Dec 16, 2008 at 5:40 PM, Ingmar Kliche
<in...@googlemail.com> wrote:
> I tried to use the o.a.c.s JEXL Context/Evaluator with an implementation of
> the <script> element. I want to make the <script> implemenation independent
> of the expression languange. But unfortunately it seems to me that EL is not
> useful (e.g. does not support assignments) and Jexl has some shortcomings:
>
> 1) I tried a script with multiple statements, like:
>
> <script>
>  x = y;
>  y = 3;
> </script>
>
> While executing this script I get:
>
> WARNUNG: The JEXL Expression created will be a reference to the first
> expression from the supplied script: "
>        x = y;
>        y = 3;"
>
> Does the JEXL implementation not support multiple statements per expression?
>
<snip/>

It does, but you have to use the ScriptFactory (as against using
ExpressionFactory) -- ties into comment above regarding a new
Evaluator#evalScript() method.


> 2) Unfortunately the o.a.c.s JexlEvaluator#eval() generates an
> "effectiveContext" (to implement the scope chain) and passes it to the JEXL
> expression for execution. Thus any modification taken by the script (like
> any assingments as "x = y") will modify the "effectiveContext", not the
> actual state context. After executing "x=y", "x" remains unchanged within
> the states context.
>
> Is the JexlContext implemenatation useful for a <script> implementation at
> all from this perspective?
>
<snap/>

Correct, the out of the box implementation isn't conducive to scripts
(writes aren't supported since those are handled via <assign>, for
example). When we make the other changes to accomodate <script>, we
will have to address this.

Interim, it should be possible to implement script as a custom action
(which is probably what you're doing here) and use your own evaluator
implementation (similar to the extended one mentioned above) which the
custom action leverages.

-Rahul


> - Ingmar.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org