Re: [Springframework-developer] Spring Enhancement

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

I think the performance issue is probably not a big deal, as you say. 
W/regards to backwards compatibility though, if strings that were 
previously plaintext in existing elements like <value> were all of a 
sudden interpreted as expressions, at a minimum people would have to go 
through all the strings and suitably escape any values (like $) that 
would trigger the expression evaluator. What would help in this respect 
and also on the performance side, is to use a prefix on the string value 
to indicate that it's an expression, e.g.
   ognl:some.expression
as Tapestry does, for example...


Mike Cannon-Brookes wrote:

>Colin,
>
>Hrm - I think an expr tag would be a start, but really I don't see why you
>can't just make everything an expr? I mean - what are the backward
>compatibility issues?
>
>Or else, have an attribute maybe like type="expr" which indicates the body
>of the tag is an expression to be evaluated? (The only real need for this I
>think is in the case of performance parsing the file - but seeing as a
>context is initialized relatively infrequently, I'm not sure this is such a
>big issue?) 
>
>Cheers,
>Mike
>
>On 7/12/03 2:49 AM, "Colin Sampaleanu" (col...@ex...) penned the words:
>
>  
>
>>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
>>>>   
>>>>