Re: [lists] Re: [Springframework-developer] Spring Enhancement

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

Sorry - but IMHO this is still adding too much complexity for very little
benefit. It adds more dependencies (OGNL is just one JAR) and realistically
I don't see it being useful. An EL within the context XML file is core to
Spring and shouldn't be pluggable - I vote for simplicity any day :)

My $0.02.

M

On 8/12/03 4:02 AM, "Peter den Haan" (pe...@de...) penned the words:

> Even if you don't use it as anything other than a source of ideas -- are you
> familiar with JEX (http://www.plotnix.com/jex/)? It's a universal API for
> expression languages, and it uses precisely this prefix method to determine
> the language used. Omit the prefix, and you get whatever default language
> you have configured. JEX expression languages are completely pluggable.
> 
> IMHO pluggability is very much in line with the Spring philosophy. My
> suggestion would be to have a configuration-file level setting for the
> default expression language. The default value for this default language
> could, of course, be the trivial expression language that interprets
> everything as a literal :)
> 
> I can see some sweet use cases for this -- say, you have an application
> which needs to pull some settings from a user-level XML configuration
> file.You could use a FactoryBean to bind the configuration file's DOM in the
> application context, pick JXPath as your expression language and use XPath
> expressions into the configuration file to pull the configuration values
> into your beans...
> 
> - Peter
> 
> 
> ----- Original Message -----
> From: "Colin Sampaleanu" <col...@ex...>
> To: <spr...@li...>
> Sent: Sunday, December 07, 2003 2:46 PM
> Subject: [lists] Re: [Springframework-developer] Spring Enhancement
> 
> 
>> 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...
> 
> 
> 
> -------------------------------------------------------
> 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