From: Colin S. <col...@ex...> - 2003-10-25 13:54:00
|
Actually OGNL has no dependencies on any servlet classes. It's designed specifically to be embeeded in other products/libs. The size and the fact that you are adding another dependency is obviously an issue though. Any way you slice it though, you are going to end up adding code to add the same functionality. In this respect, I am starting to be more of a fan of getting something pluggable in there. Perhaps it could use a quasi namespace prefix to pick the implementation, e.g.: ognl:expression anotherel:expression expression (default implementation?) Regards, Colin jürgen höller [werk3AT] wrote: >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/ > > |