I'd go with a variation of a). In terms of ignoring those properties for processes other than Password Change, I would keep a single method for validating the User object, and employ one of these options:
1. Make the validations on those new fields dependent on a condition. For example, the originalPasswordFromForm and newPasswordConfirm are only required if the newPassword has been populated. 2.Use a validation context. When calling User.validate(), pass in a context that would allow it to determine which rules should be used to test the validity of the object. Number 1 would allow for an Update screen wherein the change password fields would be optional. So a user could simply update User details without providing values for the Password Change fields, or a user could update User details while updating the password. So to me this is the more flexible option. Number 2 would work if passwords are always being updated by a specific process, which is separate from other processes involving the User object. On Sun, Oct 19, 2008 at 10:53 AM, Alan Livie <[EMAIL PROTECTED]> wrote: > > I am working on some legacy code on the basic 'change my password' use > case. > > I have a User object and a UserService object. > > The User object has a password property. However, when changing > passwords I have a User object in session with the encrypted password > stored in the 'password' property but when validating a password > change I also have the original password the user has entered in the > form (to prove its them) , the new password and the 'confirm new > password' values. > > At the moment the 'originalPasswordFromForm', 'newPassword' and > 'newPasswordConfirm' are not in the User object and the validation > happens in the service. This smells a bit as we're still talking about > a User so the User object feels like the correct place for this > validation logic to go. > > Question is how I handle the whole process of moving the logic and > avoiding headaches with generic User validation. Do I... > > a) add new properties to User object but ignore them for general > object validation and have a seperate validatePasswordChange() method > for this use case > > b) add new properties to User object and populate them when the User > is read. ie set the 'originalPasswordFromForm', 'newPassword' and > 'newPasswordConfirm' values to the same as is in 'password', thus > allowing general validation to pass when the user is simply updating > another field (except if I get stricter on password strength rules and > many existing passwords would fail validation .... so this also > smells!) > > c) keep these out of User and put in another object, either the > service or another suitable bean. > > I'm sure many of you have been here before so any suggestions > welcome :-) > > Thanks > > Alan > > > -- Bob Silverberg www.silverwareconsulting.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
