[Cosmo-dev] Account activation model, dao, service design

[Travis Vachon]

Agreed on all points.

Thanks!

-Travis

On Nov 21, 2006, at 12:13 PM, Brian Moseley wrote:

> On 11/21/06, Travis Vachon <travis at osafoundation.org> wrote:
>
>> The reason I had originally decided to go with a new service was to
>> fulfill the need for account activation to be configurable. E-mail
>> based account activation shouldn't be mandatory, and this provides a
>> mechanism for third parties to create new account activation
>> behaviors (perhaps by checking against another known authority, or
>> via a different communication channel like Jabber).
>
> point well taken, but let's not over-design to accomodate any possible
> scenario. let's think about the qualities of activation that might be
> useful to change:
>
>   - whether or not activation should occur at all
>   - various transports (email, jabber, etc)
>
> you've more or less accounted for the first point in
> StandardUserService with conditional statements. make these
> conditionals based on the value of a property that can be set with
> spring and we're golden.
>
> for the second one, i'm on board now with your thinking. i recommend
> changing the name of the interface to AccountActivator and placing it
> in the package o.o.c.service.account. none of these classes are ones
> that need to be exposed to clients of the service apis - they're used
> by service implementations and wired up with spring. i'd also
> recommend changing the name of the email implementation class to
> EmailAccountActivator rather than "default" or "standard" - those
> names imply that it's possible but unlikely to have alternate
> implementations, whereas that's totally valid in this case.
>
>> That said, I think moving this logic into UserService would work just
>> as well, since future developers could just extend UserService and
>> override initiateActivationProcess. If we were to do this, I'd say we
>> should add initiateActivationProcess, getUserFromActivationId, and
>> possibly getActivationToken to UserService.
>
> nah, i'm fine with how you had it as per the above comments. clearly
> you still need UserService.getUserByActivationId, but the other stuff
> should stay in AccountActivator. initiateActivationProcess might be
> better named something that more clearly describes the action -
> sendActivationMessage? getActivationToken actually causes a token to
> be calculated, rather than retrieved from storage, so i'd call that
> generateActivationToken.
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev