Reverse attribute mapping..

Rod Widdowson rdw at steadingsoftware.com
Wed Aug 7 04:01:07 EDT 2013


> >>Further feedback?
> 
> I suggest not mixing <property> and p-namespace to avoid potential
> confusion.

Within a whole file, or just per bean?  If the former then I'll not bother
to look at short cutting lists via XML lists since it gains us nearly
nothing.  I can certainly see utility in the latter since then we could use
the p-namespace for the value mappers and <properties> for the rest.

Of course this problem goes away if I made the attributeValueMappers
stateless (because then we can use p-namespace throughout), but that would
either be ugly in the code or (more likely) make logging much less useful.
It seems that neither are good compromises against ease of config..

As an aside: it also strikes me that the "abstractStringMapper" is the place
to deal with the (system wide) default for format as scott describes in
IDP207.  Do we want to do this programmatically  as well?

And I'm still hoping that crafting these files can be made into an edge
case.
 
> I think that the bean name (the "id" attribute) and the "id" property
> should have the same value, or am I missing something ?
>  <bean id="RequestedAttributesMapper" ... p:id="Mappers">

Good point.  They don't have to be the same, but that way madness lies...
I've changed it.

> How about an idp-attribute-mapper-api|impl module ? Mapping seems
> different from resolution and filtering, is somewhat "new" to v3, and
> whether we use native Spring XML or custom I think a separate module
> is okay. The "long" class names make me think : new module.

As Scott says they obviously don't belong in the filter (except that this is
their only user).  Beyond that I have no opinions - I *know* that I suck at
naming and placing classes and I'm always glad to take direction on that.

/R



More information about the dev mailing list