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

[Peter d. H. <pe...@de...>]

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