Addition to allow alternate ExpressionEvaluators

["Frederick N. Brier" <fb...@multideck.com>]

We are using Webwork2 as an app framework on a project (I am actually 
using Struts on a different project).  It would be great to be able to 
use the JSTL with Webwork's value stack.  Apparently the JSTL (at least 
version 1.0) was designed to allow swapping out ExpressionEvaluator(s), 
but is missing one small key method in ExpressionEvaluatorManager. 

       /**
        * Enhancement to allow plugging in alternate expression engines.
        * @param expressionEvaluator implements the Jakarta JSTL
        * ExpressionEvaluator interface for your app framework.
        */
       public static void installExpressionEvaluator(
    ExpressionEvaluator expressionEvaluator )
       {
          nameMap.put( EVALUATOR_CLASS, expressionEvaluator );
       }

The default behavior is unchanged.  If someone could add this, I would 
be extremely grateful.  This is integrated into Webwork with 2 small 
classes: A ServletContextListener, that calls the above method and 
installs the WebworkExpressionEvaluator, and the 
WebworkExpressionEvaluator itself.  Add the listener to your web.xml and 
you are done.  The above 2 classes have already been posted to the 
Webwork mailing list.  If desired, I could write up a How-To page.  
Thank you for your help.

Frederick N. Brier
Multideck Corporation

Re: Addition to allow alternate ExpressionEvaluators

[Shawn Bayern <ba...@essentially.net>]

On Sun, 19 Oct 2003, Frederick N. Brier wrote:

> There is not a standard framework yet, and even if there was, creating a
> perfect, one size fits all, is a tall order.  Declaring the JSTL a
> standard, while preventing its integration with existing frameworks is
> putting the cart before the horse, and hamstrings its applicability.  I
> think a standard expression language is a good idea.  It just should not
> be - the only one.

One advantage of JSTL -- and of course JSP itself -- is that it can be
implemented differently by different vendors; this allows for
optimizations and other behind-the-scenes improvements by specific
vendors.  The text "${x}" -- in appropriate context -- has a meaning
defined by the JSTL standard; if you add hooks to one JSTL implementation
to alter this meaning, then pages that are based on such hooks will be
tied to the specific implementation you've modified.  For instance, your
page wouldn't be portable from the Standard Taglib (Jakarta Taglibs's
implementation of JSTL) to Resin's implementation or any other.

Moreover, JSTL -- and the expression language generally, as part of JSP
2.0 -- is aimed at page authors.  If you alter the meaning of "${x}", such
page authors will need to look beneath the surface of the page they're
writing to determine what's going on; one hypothesis of JSTL is that its
users might not even be aware of deployment descriptors.

I've never suggested that a single framework or language should be used to
the exclusion of all others.  The mechanism you propose for integrating
different frameworks, however, creates more problems than it addresses;
the language isn't the appropriate point of extension in JSTL.  I'd
suggest thinking in terms of back-end logic that exposes objects or custom
taglibs that interact with JSTL.  (I'm not particularly familiar with
WebWork -- and not even working in information technology anymore! -- so I
regret that I can't be more helpful in suggesting specific alternatives.)

Shawn


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

Re: Addition to allow alternate ExpressionEvaluators

["Frederick N. Brier" <fb...@multideck.com>]

Shawn,

Thank you for your reply.  It is appreciated.  In response though, 
Entity Beans are a standard.  Does not necessarily mean it is a good 
idea.  Or even if it is, whether it is a good idea for every project 
architecture and set of requirements.  Flexibility without introducing 
complexity is a good thing.  There are dozens of frameworks out there, 
some like Webwork whose architecture is linked with the concept of a 
value stack and expression language.  Most have their own small tag 
library to support their framework.  This JSTL modification allows 
complete integration with another framework with a few lines of 
configuration in the web.xml.  Personally, I would refine it further and 
look for additional ways to make the JSTL even more extensible.

There is not a standard framework yet, and even if there was, creating a 
perfect, one size fits all, is a tall order.  Declaring the JSTL a 
standard, while preventing its integration with existing frameworks is 
putting the cart before the horse, and hamstrings its applicability.  I 
think a standard expression language is a good idea.  It just should not 
be - the only one.

Frederick N. Brier
Multideck Corporation

Shawn Bayern wrote:

>On Sun, 19 Oct 2003, Frederick N. Brier wrote:
>
>  
>
>>We are using Webwork2 as an app framework on a project (I am actually
>>using Struts on a different project).  It would be great to be able to
>>use the JSTL with Webwork's value stack.  Apparently the JSTL (at least
>>version 1.0) was designed to allow swapping out ExpressionEvaluator(s),
>>but is missing one small key method in ExpressionEvaluatorManager.
>>    
>>
>
>Early pre-release JSTL implementations allowed pluggable expression
>evaluators to encourage experimentation with multiple languages before
>standardization.  Once the expert group settled on the details of the
>standard Expression Language, we deliberately removed this support.  If it
>were permitted, most of the benefits of standardization would be lost.
>
>  
>

Re: Addition to allow alternate ExpressionEvaluators

[Shawn Bayern <ba...@essentially.net>]

On Sun, 19 Oct 2003, Frederick N. Brier wrote:

> We are using Webwork2 as an app framework on a project (I am actually
> using Struts on a different project).  It would be great to be able to
> use the JSTL with Webwork's value stack.  Apparently the JSTL (at least
> version 1.0) was designed to allow swapping out ExpressionEvaluator(s),
> but is missing one small key method in ExpressionEvaluatorManager.

Early pre-release JSTL implementations allowed pluggable expression
evaluators to encourage experimentation with multiple languages before
standardization.  Once the expert group settled on the details of the
standard Expression Language, we deliberately removed this support.  If it
were permitted, most of the benefits of standardization would be lost.

-- 
Shawn Bayern
"JSTL in Action"   http://www.jstlbook.com


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