|
From: Alef A. <al...@jt...> - 2003-12-06 16:23:40
|
I've introduced an issue in JIRA for this, though I'd emailed about it already, but saw just now that I didn't change my smtp-server when changing from work to home network... Alef -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Colin Sampaleanu Sent: Saturday, December 06, 2003 4:50 PM To: spr...@li... Subject: Re: [Springframework-developer] Spring Enhancement I was planning to add (optional) OGNL support in about 2-6 weeks (depending on when we start working on 1.1 features. Now what I was going to do was a relatively transparent implementation, where a new <expr> element would be usable anywhere <value> now is, i.e. <property name="whatever"> <expr>ognl:an.ognl.expression</expr> </property> Allowing usage of expression in existing elements, like <key>, would be possible, but has some implications in terms of backwards compatibility... Mike Cannon-Brookes wrote: >Or an even better idea... how about supporting OGNL within the Spring >config files? (like Xwork does) > >This would be _awesome_ and I just found a second use case for it (the >very minute Rob's email came in). > >My use case - Maps. > >The Map syntax is nice, but not very useful in practicality I'm finding >as the key and value of the map are usually related, for instance I >often want to put a list of referenced beans into a map, with >ref.getName() (or some >method) called for the key. > >At the moment I have to add a setBeans(List) method to my class, and >then in that setter iterate and add to a map - smelly! > >If we allowed OGNL expressions, it would be very simple to do this in >the config file itself: > ><property value="myMapProp"> > <map> > <entry> > <key>$referencedBean.name</key> > <value><ref bean="referencedBean" /></value> > </entry> >... More entries > </map> ></property> > >I'm sure there are a million other places where OGNL would be useful >too, but AFAIK the above can't be done _without_ it? > >Or have I just been at this desk far too long? > >M > >On 2/12/03 8:32 AM, "Rob Butler" (rob...@ve...) penned >the >words: > > > >>Spring now provides the ability to instantiate an object using either >>a JavaBean no arg constructor, or any normal Java constructor. But it >>does not support calling methods. >> >>Also, Spring requires that a class implement the InitializingBean >>interface if it needs to perform some "setup" work after the setters >>have all been called. This means that any class that has this need is >>tied to the Springframework. >> >>What if the ability to call any arbitrary method was added to Spring? >>Then users could call "afterPropertiesSet" to do "setup" work without >>having to implement the InitializingBean interface. Ideally method >>calls could be in any order along with calls to setters. Spring would >>then call each in order. Thus, allowing some setters to be called, >>then some methods, then more setters if necessary. If this is not >>possible, then methods should be called after setters. >> >>This would allow complete decoupling of classes from Spring. The >>InitializingBean & BeanFactoryAware interfaces would no longer be >>needed (although could remain for backwards compatibility). This >>would be very useful when contributing code to other projects that do >>not want to have a dependency on Spring. Also, it would allow >>virtually any class used by /developed for another IOC framework / >>lightweight container to be used in Spring. >> >>Thoughts? >> >>Later >>Rob >> >> ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |