Re: [Springframework-developer] Spring Enhancement

[Colin S. <col...@ex...>]

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
>>    
>>