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

[Brian Moseley]

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.