RE: [Springframework-developer] FW: [springframework - Help] Index properties in forms

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

I'm no expert on JSP 2.0, but at first glance it appears that the new EL =
API is no longer excessively tied into web objects.

They seem to have introduced a VariableResolver interface. Each time an =
EL expression is evaluated, the VariableResolver is used to map top =
level variable names into Objects. Presumably the default =
VariableResolver maps everything into the PageContext, but if I =
understand things correctly, EL implementations compatible with JSP 2.0 =
(one of which is presumably part of Tomcat) are necessarily going to be =
usable outside of web applications, simply by implementing an =
appropriate VariableResolver.

I bring this up now because I too would be a big fan of using JSTL EL =
syntax as one of (or even the default) bean mapping syntaxes.

JWS

-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]=20
Sent: Friday, October 24, 2003 7:19 AM
To: spr...@li...
Subject: Re: [Springframework-developer] FW: [springframework - Help] =
Index properties in forms

Peter,

I tend to agree that JSP EL syntax is preferable, although we are not =
talking about a web-specific thing here. We have to build this into =
BeanWrapperImpl in any case, as we need to do lookups of custom property =
editors etc to provide the same level of functionality as for current =
nested properties. I doubt that we could reuse any existing EL =
implementation for this, as they all work on a JSP PageContext. =
Generally, we should try to avoid any additional dependencies for the =
core bean factory.

Juergen

-----Original Message-----
From: Peter den Haan [mailto:pe...@de...]
Sent: Friday, October 24, 2003 1:25 AM
To: spr...@li...
Subject: [[W3-SPAM]] - Re: [Springframework-developer] FW: =
[springframework - Help] Index properties in forms - Email found in =
subject

Juergen wrote:

> The question is: When and how to we add support for indexed and mapped
properties?
> I guess that if we do, we should adopt the Commons BeanUtils style of
specifying property
> paths for index and map access.

I disagree. I feel we should use (a subset of) the JSTL Expression =
Language
(EL) syntax as our starting point rather than BeanUtils style syntax. =
Please consider that this EL will be part of JSP itself as of version =
2.0 of the spec; why introduce another language into the mix? If in a =
JSP you say ${foo.bar}, shouldn't you be able to name the corresponding =
field foo.bar rather than foo(bar)?

For simple and indexed properties, users won't notice any difference =
anyway. The most important differences are that the precise meaning of =
a[b] is determined by whether "a" evaluates to a List or a Map, and that =
a.b is fully equivalent to a["b"]. BeanUtils-style mapped properties =
(i.e. a(b)) aren't part of the EL; they could be supported in a =
compatible way but IMHO stick with core JavaBeans stuff -- do this only =
if we can come up with a compelling use case for it.

And if this is being refactored anyway, it's probably worth taking a =
look at what would be involved in making the EL implementation =
pluggable.

 - Peter

-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program. Do you =
like what SourceForge.net is doing for the Open Source Community?  Make =
a contribution, and help us add new features and functionality. Click =
here: http://sourceforge.net/donate/ =
_______________________________________________
Springframework-developer mailing list =
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program. Do you =
like what SourceForge.net is doing for the Open Source Community?  Make =
a contribution, and help us add new features and functionality. Click =
here: http://sourceforge.net/donate/ =
_______________________________________________
Springframework-developer mailing list =
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer