Re: [Springframework-developer] Spring Enhancement

[Mike Cannon-B. <mi...@at...>]

But would anyone _actually_ have $ signs in their files? I suppose for
property values they might - I was thinking of bean references. Are $ valid
in bean names?

Not averse to a prefix though - like ognl: - seems simple enough and very
unlikely to create any backwards compatibility problems.

Cheers,
Mike

On 8/12/03 1:46 AM, "Colin Sampaleanu" (col...@ex...) penned the words:

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