[IdP]<SAMLObjectName>

[Rod Widdowson]

I'm just about to push the change with the most obvious of these changed.
This is usually the setters and getters (for instance
AttributeFilterContext#getPrefilteredIdPAttributes())

I did this by eyeballing the -api Classes and Interfaces and letting the
refactor trickle through.

However I find myself in two minds about cases such
AttributeResolver#finalizeResolvedAttributes(AttributeResolutionContext): we
are certainly manipulating IdPAttributes here, but do we need to be
explicit?  I am thinking so and the method should become
finalizeResolvedIdPAttributes.

Another case is
AtttributeResolver#getToBeResolvedAttributes(AttributeResolutionContext)
which is returning a list of attribute names not the attributes themselves.
Perhaps this has to be named getToBeResolvedAttributeNames?

But there is a risk of (a) over long method names which we all love so much
and also of (b) Yack Shaving.

Thoughts?

Rod

> -----Original Message-----
> From: dev-bounces at shibboleth.net [mailto:dev-bounces at shibboleth.net]
> On Behalf Of Cantor, Scott
> Sent: 19 October 2013 19:41
> To: Shib Dev
> Subject: Re: [IdP]<SAMLObjectName>
> 
> On 10/19/13 10:07 AM, "Rod Widdowson" <rdw at steadingsoftware.com>
> wrote:
> 
> >I thought about this and decided not, but I'll take guidance.
> 
> I think it's worth it for consistency/clarity.
> 
> The resolver and filter really deal entirely with IdPAttribute AFAIK
> (barring special add-ons like a SAML query inside a data connector or
> something).
> 
> -- Scott
> 
> 
> --
> To unsubscribe from this list send an email to dev-
> unsubscribe at shibboleth.net