ConsentFlowDescriptor extends ProfileInterceptorFlowDescriptor ?

[Cantor, Scott]

On 9/24/14, 9:48 PM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:
>>>
>>>I'm assuming that consent actions will be operating on a
>>> ConsentContext, so there will be an AbstractConsentAction. Should it
>>> extend AbstractProfileAction or AbstractProfileInterceptorAction ? My
>>> first thought was AbstractProfileInterceptorAction, but that seems too
>>> deep. And, the ConsentContext should hang off the PRC, not the
>>> ProfileInterceptorContext, right ? Or is that weird.

The consent concept is internal to a single flow of that type at the
moment, so I don't know, it just depends what you need.

Doesn't matter that much where you put the contexts, whatever seems
simplest probably, which usually means directly off the PRC for me.

>>>We talked about a ProfileInterceptorResult, which I assume would be a
>>> field of the ProfileInterceptorContext, which a, say,
>>> WriteProfileInterceptorResultToStorage action would write to a storage
>>> service at the end of an interceptor flow. I guess a consent action
>>> could locate the ProfileInterceptorContext via a lookup strategy
>>> function and then get access to the interceptor result.

Yeah, I basically use look functions everywhere now just for defensive
reasons.

>> Oh, and I'm assuming that the ConsentFlowDescriptor would be a field
>> of the ConsentContext. So, if the flow descriptors have a parent-child
>> relationship, it seems the context and abstract action would as well,
>> I guess for symmetry. But, it seems we generally hang contexts off the
>> top level PRC unless some need arises.

It's not exactly parent/child though, it's inheritance, and that's not
possible to do with the context types because of the way the tree works.
But if it's simple to hang it off the InterceptorContext, that's fine too.
It really only matters to the default functions you create  in the actions.

>Then, the profile interceptor flow descriptor and context would need
>to move to profile-api to avoid dependencies on profile-impl, is that
>what we want to do ? The interceptor result would need to be in -api
>too it seems.

Yes, I expected all of those to be in the API module.

-- Scott