Menu
▾
▴
RE: OGNL support WAS: [Springframework-developer] Spring Enhancement
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-12-03 22:38:29
|
Mike, This was discussed about a month ago shortly (see quoted email below). I think this is definitely a feature worth while considering! But I don't think it's possible to include his before 1.0final. We can put it on the wishlist? Alef <QUOTE EMAIL OCTOBER 17TH> A richer expression language would have its use cases. The right thing to do might be to make the language pluggable :^) A little while ago I rolled a simple generic Validator implementation -- configured using the Spring configuration file -- using JEX (http://www.plotnix.com/jex/). This a little pluggable expression language framework. I added JEX plugins for regexps and the JSTL expression language so I could use these (in addition to JavaScript, BEXL and JXPath) to formulate validation rules. I never fed this back to the list because the implementation is not quite generic enough (eg there's no i18n support), but having used it for a while it seems there's a fair bit of mileage in the idea. A decent expression language is IMHO exactly what's missing from the brilliant-idea-but-flawed-execution Struts Validator. In any case, I can think of a number of reasons why it might be good to adopt JEX or a Spring equivalent of it. On a not entirely unrelated note, one of the things I've been missing from Spring is what you might call "anonymous beans". In some situations, I don't really want to pollute the namespace with beans that will only ever be used in one place: <bean id="foo" class="eg.Foo"> <property name="bar"><ref bean="bar"/></property> </bean> <bean id="bar" class="eg.Bar"/> But would like to be able to write something like <bean id="foo" class="eg.Foo"> <property name="bar"><bean class="eg.Bar"/></property> </bean> Has this been discussed before? Spring is the best thing I've come across for a while and I'd love to contribute something back :^) - Peter ----- Original Message ----- From: "Colin Sampaleanu" <col...@ex...> To: <spr...@li...> Sent: Wednesday, October 15, 2003 8:17 PM Subject: [lists] [Springframework-developer] Expression language for use in ApplicationContext > Has an expression language available for use in the app context ever > been considered? (as per email below) > > -------- Original Message -------- > Subject: Re: Spring XMLBeanFactory > Date: Wed, 15 Oct 2003 15:14:42 -0400 > From: Colin Sampaleanu <col...@ex...> > To: Vladimir Blagojevic <vla...@cs...> > References: <Pin...@bl...> > > > > It can't do this (to the best of my knowledge). There is an expression > language available for use in the JSP tags, but this is not accessible > in the contexts. > > If there is enough of a use case for this it could certainly be done. > One way would be to try leveraging the existing expression language > code. I have no idea how easy this would be to do since I've actually > never touched the web ui code. Another mechanism would be to bring in > something like OGNL, which is quite powerful... > > What is your usage scenario? > > > Vladimir Blagojevic wrote: > > >Colin, > > > >Does XMLBeanFactory support reading property of bean X and assigning > >it to bean Y within declarative xml config file? I don't think so, > >but is there any chatter on the lists about that? > > > >Cheers </QUOTE EMAIL OCTOBER 17TH> > -----Oorspronkelijk bericht----- > Van: spr...@li... > [mailto:spr...@li...] > Namens Mike Cannon-Brookes > Verzonden: Wednesday, December 03, 2003 11:04 PM > Aan: Spring > Onderwerp: OGNL support WAS: [Springframework-developer] > Spring Enhancement > > > Any thoughts on this guys? I can't find any replies to it :) > > ------ Forwarded Message > From: Mike Cannon-Brookes <mi...@at...> > Reply-To: spr...@li... > Date: Tue, 02 Dec 2003 16:02:58 +1100 > To: Spring Developer <spr...@li...> > Subject: Re: [Springframework-developer] Spring Enhancement > > 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: SF.net Giveback Program. Does > > SourceForge.net help you be more productive? Does it help > you create > > better code? SHARE THE LOVE, and help us help YOU! Click Here: > > http://sourceforge.net/donate/ > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > > https://lists.sourceforge.net/lists/listinfo/s> pringframework-developer > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us > help YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > ------ End of Forwarded Message > > > > ------------------------------------------------------- > This SF.net email is sponsored by OSDN's Audience Survey. > Help shape OSDN's sites and tell us what you think. Take this > five minute survey and you could win a $250 Gift Certificate. > http://www.wrgsurveys.com/2003/osdntech03.php?> site=8 > > _______________________________________________ > > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |