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

[Travis Vachon]

Hi Brian

Thanks for the comments. I've responded in line.

>> Service level changes:
>>     * New service interface "AccountActivationService" with four
>> methods:
>>        - public String getActivationToken()
>>        - public void initiateActivationProcess(User user)
>>        - public void activateUserFromToken(String activationToken)
>>        - public User getUserFromToken(String activationToken)
>
> why a new service? UserService is intended to provide all operations
> related to users.'

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).

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.

I agree that "activateUserFromToken" should be removed in either  
case, since this is just "getUserFromActivationId(id).activate()". I  
could also be convinced that getActivationToken shouldn't be a  
service level method, but it does seem like an "activation method"- 
specific idea that future devs might want to change.

To summarize, I think we should do either

A)
Service level changes:
    * New service interface "AccountActivationService" with three  
methods:
        - public String getActivationToken()
        - public void initiateActivationProcess(User user)
        - public User getUserFromActivationId(String activationToken)

or

B)
Service level changes
    * Two (possibly three) new methods in "UserService"
        - public void initiateActivationProcess(User user)
        - public User getUserFromActivationId(String activationToken)
        - (maybe) public String getActivationToken()


It seems like putting this logic into the client code would be  
unnecessarily limiting, but I'm willing to defer to other folks  
experience!


>
> btw, this would have been a lot easier to communicate with a couple
> uml diagrams - one class diagram for the model changes and one
> sequence diagram to describe the workflow.

Good call, I'll go with that in the future. Thanks for the reminder!

-Travis

> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev