My initial feeling is that EL support within the xml isn't a good
idea, and most of the reasons why have been articulated in this
thread. However, last time I talked to Chris about ColdSpring he was
working on the BeanFactoryPostProcessor api, which will allow you to
have greater control over the values that are set into beans.
The ${} syntax we support is basically a hard-coded
BeanFactoryPostProcessor (PropertyPlaceholderConfigurer, specifically)
- but in the future you'll be able to write your own. So if you want
to write one that calls evaluate() on any arbitrary value before it's
injected into a bean, you'll be able to do that. I highly recommend a
more sane approach - like either the PlaceHolderConfigurer we baked in
or something like Spring's PropertyOverrideConfigurer - allowing you
to override any existing values in the BeanFactory. The cool thing is
that if CS sees a bean that implements BeanFactoryPostProcessor, it
will use it within the factory in which it's defined (and any children
factories).
-Dave
On 9/23/06, Matt Williams <[EMAIL PROTECTED]> wrote:
On 9/22/06, Sean Corfield <[EMAIL PROTECTED]> wrote:
> Fusebox 4 and on has allowed evaluation of arbitrary expressions in
> certain context. Mach II also does this (the variable= attribute). I'm
> not sure whether Model-Glue has any evaluation contexts like that but
> there are clearly precedents for this sort of thing.
One of the things I don't like about Fusebox XML (no offense Sean) is
the allowance of If's, Loops, etc. It seems to put the wrong type of
code in a place it doesn't belong. I would be curious as M. Woodward
was if there is something you just cannot do because of the lack of
functions in the XML. Adding a config bean of whatever nature allows
you to do what CF functions you want and then be injected wherever you
like.
So, FWIW, a vote against - until convinced otherwise.
--
Matt Williams
"It's the question that drives us."