You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-dev@jakarta.apache.org by Christopher Lenz <cm...@gmx.de> on 2002/01/24 20:28:19 UTC
[standard] [PATCH] More EcmaScript improvements
Hi all,
Seeing that my other changes to the EcmaScript in JSTL
support were committed, I'm sending another patch. This
time it's a pretty complete overhaul of the way the
JavascriptExpressionEvaluator is implemented:
- Multiple scopes for script execution:
Inspired by the tips and guidelines in the "Embedding
Rhino" section of the Rhino documentation, I've split
the execution scope for scripts into three parts:
Global (cached as application context attribute),
Page (cached as page context attribute) and
Local (created for every expression evaluation).
This improves performance because the standard
JavaScript objects only need to be initialized once
during the application lifecycle.
- Custom scope to represent the JSP PageContext:
The Page scope mentioned above is not a standard
JavaScript object like the global and the local scope,
but rather a custom implementation of the Scriptable
interface which wraps around the PageContext (called
ScriptablePageContext). First and foremost it
provides access to all the attributes without having
to add them to the scope for every page or even every
evaluation (i.e. they are retrieved on request). In
addition, it provides access to host objects, which
are currently Maps of the request parameters, request
headers, cookies and context initialization parameters.
- Separation of compilation and execution of scripts:
Expressions are not now longer directly evaluated, but
rather first compiled into "Script" objects and stored
in a cache. This is functionaly equivalent to how the
SPEL Evaluator works. The caching introduces a huge
performance gain of course.
- Proper cleanup of Rhino contexts:
Rhino "Context" objects are now 'closed' using the
Context.exit() method after Script execution. This lets
Rhino do the cleanup it deems necessary.
- Implementation of the validate() method:
The EcmaScript Evaluator now implements the validation
method by trying to compile the expression. This also
puts the resulting Script object in the cache, so
theoretically the cache should be populated by the time
the page is executed. However, I couldn't get the
validate() method to actually get called :P
- JavascriptExpressionEvaluator now extends Evaluator
Instead of creating an instance of the SPEL Evaluator
for every evaluation of a literal, we can now simply
delegate to the super-class for that task. Ideally
there'd be an AbstractEvaluator or something like that,
of course.
All in all I think this implementation performs far better
than the current simpler implementation. Most of the source
is pretty extensively commented.
The archive contains a patch for
JavascriptExpressionEvaluator, the new
ScriptablePageContext class and changes to the examples
webapp (ParameterAccess.jsp replaced by SpecialObjects.jsp,
which contains examples of accessing parameters, headers,
cookies and init-parameters).
What do you think?
-chris
________________________________________________________________
cmlenz at gmx.de
Re: [standard] [PATCH] More EcmaScript improvements
Posted by horwat <Ju...@Sun.com>.
I've looked it over and I think this is a great improvement over the current
JSTL ecmascript support. The old implementation was very inefficient. The
pagecontext scope is a great addition.
Justy
----- Original Message -----
From: "Christopher Lenz" <cm...@gmx.de>
To: "Tag Libraries Developers List" <ta...@jakarta.apache.org>
Sent: Thursday, January 24, 2002 11:28 AM
Subject: [standard] [PATCH] More EcmaScript improvements
> Hi all,
>
> Seeing that my other changes to the EcmaScript in JSTL
> support were committed, I'm sending another patch. This
> time it's a pretty complete overhaul of the way the
> JavascriptExpressionEvaluator is implemented:
>
> - Multiple scopes for script execution:
> Inspired by the tips and guidelines in the "Embedding
> Rhino" section of the Rhino documentation, I've split
> the execution scope for scripts into three parts:
> Global (cached as application context attribute),
> Page (cached as page context attribute) and
> Local (created for every expression evaluation).
> This improves performance because the standard
> JavaScript objects only need to be initialized once
> during the application lifecycle.
>
> - Custom scope to represent the JSP PageContext:
> The Page scope mentioned above is not a standard
> JavaScript object like the global and the local scope,
> but rather a custom implementation of the Scriptable
> interface which wraps around the PageContext (called
> ScriptablePageContext). First and foremost it
> provides access to all the attributes without having
> to add them to the scope for every page or even every
> evaluation (i.e. they are retrieved on request). In
> addition, it provides access to host objects, which
> are currently Maps of the request parameters, request
> headers, cookies and context initialization parameters.
>
> - Separation of compilation and execution of scripts:
> Expressions are not now longer directly evaluated, but
> rather first compiled into "Script" objects and stored
> in a cache. This is functionaly equivalent to how the
> SPEL Evaluator works. The caching introduces a huge
> performance gain of course.
>
> - Proper cleanup of Rhino contexts:
> Rhino "Context" objects are now 'closed' using the
> Context.exit() method after Script execution. This lets
> Rhino do the cleanup it deems necessary.
>
> - Implementation of the validate() method:
> The EcmaScript Evaluator now implements the validation
> method by trying to compile the expression. This also
> puts the resulting Script object in the cache, so
> theoretically the cache should be populated by the time
> the page is executed. However, I couldn't get the
> validate() method to actually get called :P
>
> - JavascriptExpressionEvaluator now extends Evaluator
> Instead of creating an instance of the SPEL Evaluator
> for every evaluation of a literal, we can now simply
> delegate to the super-class for that task. Ideally
> there'd be an AbstractEvaluator or something like that,
> of course.
>
> All in all I think this implementation performs far better
> than the current simpler implementation. Most of the source
> is pretty extensively commented.
>
> The archive contains a patch for
> JavascriptExpressionEvaluator, the new
> ScriptablePageContext class and changes to the examples
> webapp (ParameterAccess.jsp replaced by SpecialObjects.jsp,
> which contains examples of accessing parameters, headers,
> cookies and init-parameters).
>
> What do you think?
> -chris
> ________________________________________________________________
> cmlenz at gmx.de
>
>
----------------------------------------------------------------------------
----
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>