"Native" spring configuration for attribute filters

[Rod Widdowson]

> I think for us it may be natural to create a lot of separate beans and
> reference them, the more comparable approach is nesting or inline beans
> because that's more natural to people not versed in coding.

Makes sense - at least for the "obvious" cases.  I think that not having
hand built beans for the non obvious case (for instance "activate this
policy if any attribute has this value") will help with gun-foot-bullet
issues.
 
> It's not just hiding stuff, but creating all the syntactic help that
simplifies the
> wiring.

True.  This is where we need to rely on your (Scott's) experience with doing
the initial stuff.
 
> The question I have is whether our time is better spent on this, or on
actually
> creating a simpler language (which may or may not be using native wiring,
but
> likely would).
> 
> Or whether the use cases for such a change are in fact easy to make simple
> to wire up now so that a new filter engine isn't warranted, just de-
> emphasizing the more complex features.

Again I'm not sure.  I'm pretty code-blind and so I'm not sure how much
positive stuff I could contribute to a new language.  

OTOH if we did decide to push a native spring format I think we could not a
lot worse than deprecating the use of Policies and replace them with our
standard Predicates.  We would obviously need to provide analogous
predicates for all the Policies that we have thus far but I'd view it as a
positive to have a larger bucket of Predicates available.  (except of course
that a Policy returns a tristate and a predicate a boolean so we would need
a strategy there). 

Rod