Return-Path: Delivered-To: apmail-jakarta-taglibs-dev-archive@apache.org Received: (qmail 70899 invoked from network); 25 Jan 2002 23:23:14 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 25 Jan 2002 23:23:14 -0000 Received: (qmail 4603 invoked by uid 97); 25 Jan 2002 23:23:17 -0000 Delivered-To: qmlist-jakarta-archive-taglibs-dev@jakarta.apache.org Received: (qmail 4554 invoked by uid 97); 25 Jan 2002 23:23:16 -0000 Mailing-List: contact taglibs-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tag Libraries Developers List" Reply-To: "Tag Libraries Developers List" Delivered-To: mailing list taglibs-dev@jakarta.apache.org Received: (qmail 4543 invoked from network); 25 Jan 2002 23:23:16 -0000 Message-ID: <163a01c1a5f7$f140b760$9608fea9@neuromancer> From: "horwat" To: "Tag Libraries Developers List" References: <3XWV1T08A0B9SPA08NM41PJRQEURJG.3c506053@athlon> Subject: Re: [standard] [PATCH] More EcmaScript improvements Date: Fri, 25 Jan 2002 15:28:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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" To: "Tag Libraries Developers List" 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: > For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: