Don, 

I wanted to comment on the idea of plugging expression languages into the 
current code, because as one who has written a lot of the recent type 
conversion code and delved deeply into OGNL, I would say this is a difficult, 
though not impossible task. The issue is that all the property accessor classes 
and method accessor classes that are so integral, are all OGNL related. 
Removing that would also remove a lot of functionality of XWork.

However, it is not impossible. OGNL depends on a language file which generates 
all of the classes that are used for evaluating an OGNL expression. Knowing the 
language file is knowing OGNL and being able to modify it. It would then 
perhaps be possible to create language files in any EL we like, which would 
then still go through all the property accessors (or method accessors) as we 
like and handle null properties as well, which would be nice to do independent 
of EL.

Another option, possibly usable in the paragraph above is to make OGNL more 
like JSTL or a more standard language but 'extend' it. In this option, OGNL 
would look much like JSTL (which in a lot of ways it already does such as Map, 
List and property accessing), but using the action taglibraries (the former 
webwork taglibraries) one would be able to use the extended functionality of 
OGNL such as method accessors. Since OGNL isn't really in development, we ought 
to feel free to develop it to our purposes.

Just some thoughts to thow out there on a tangential topic. 

Gabe

----- Original Message ----
From: Don Brown <[EMAIL PROTECTED]>
To: Struts Developers List <dev@struts.apache.org>
Sent: Sunday, April 9, 2006 3:07:26 PM
Subject: Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)

Sorry, I should be more clear when discussing EL.  An Expression 
Language or EL is a concept I think we all agree is a good thing.  
Implementations of EL include JSP 2.0, JSF 1.0, the Unified EL, OGNL, 
Jexl, JXPath, and many others.  Struts 1.x used a poor man's EL through 
Beanutils, which lacked many of the features you now associate with EL.  
The Unified EL is used by the next JSF and JSP (2.1 I think) with the 
purpose of unifying the different incarnations of EL they both used.  
OGNL is used by Action 2/WebWork, Tapestry, Wicket, and several others.  
It is the most advanced EL with the most features, however some of those 
aren't well documented.

My point was first, Action 2 should allow you to plug in any EL you'd 
like, including the Unified EL, and second, at this point, I don't see 
the Unified EL replacing OGNL for primarly usage, mainly because the 
Unified EL lacks several key features, the lack of which is a conscious 
decision of the working group.  Still, I'm sure there will be those 
Action 2 users who would rather have the familarity of the Unified EL 
over the advanced features of OGNL, so we hope to make that an option 
some day.

Don

Michael Jouravlev wrote:
> On 4/9/06, Don Brown <[EMAIL PROTECTED]> wrote:
>   
>> Using
>> EL, on the other hand, I personally don't see as a great benefit.  The
>> new unified EL lacks many of the key features that makes EL and OGNL in
>> particular, so attractive.  For example, OGNL supports method
>> invocation, type conversion, and projection, features, AFAICT, aren't
>> supported by EL and won't ever be.
>>     
>
>
> I see an advantage of unified EL in creating proper names for HTML
> input elements and automatic propagation if input data to backing
> beans. Basically, this is kind of Struts HTML tags + beanutils +
> proper type conversion or WebWork tags + OGNL. Doing it JSF way is
> more unified, instead of having different Struts 1, Struts 2 or
> Stripes way. This feature is not planned for JSP 2.1, but I think it
> can be implemented. Sun pushes JSF and implements new features in JSF
> only.
>
> Michael.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to