"Native" spring configuration for attribute filters

[Cantor, Scott]

On 9/2/15, 11:01 AM, "dev on behalf of Rod Widdowson" <dev-bounces at shibboleth.net on behalf of rdw at steadingsoftware.com> wrote:



>My take-aways are:
>
>- This was not hard and once I got going it became quite mechanical.
>
>- The results are no more impenetrable than the custom syntax

I think they're a bit more impenetrable now, but that's largely because this is the very beginning of coming up with a strategy and not the end of it. We also could make changes to parameter and argument names to facilitate some of this because none of those names were an API anyway.

>- That weird things like plumbing natural Matchers into Policy roles shows
>itself up by having more complex plumbing whereas in the custom syntax the
>inherent complexity is masked.  See policy5.xml.

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.

>- That before we went live with this we would need to define a bunch of
>abstract beans to hide the impl nature of most of the actual matchers and
>policy rules.

It's not just hiding stuff, but creating all the syntactic help that simplifies the wiring.

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.

-- Scott