@Alan I think with the UPS parcel example, I'm fairly sure that at some point in the reachDestination() call, it would delegate to methods on other objects (or libraries) for specialised bits of functionality - I'm thinking here of geolocation or international calendar functionality for deliveries across international boundaries and different time zones for instance...
It might be useful to separate out specialised areas of functionality so that other objects can make use of them without having to worry about instantiating the original client object - e.g. "Hey man, that getLocalTime(longitude,latitude, UTC) function is way cool, but why do you have to instantiate a UPSParcel object to use it?"... I'd agree that in this specific case the requirement to reuse a Password object outside of the User object might be limited but it's not beyond the realms of possibility (and here we get into YAGNI discussions) e.g. a generic security library for use across multiple applications... On Oct 22, 5:50 pm, Alan Livie <[EMAIL PROTECTED]> wrote: > @Brian. I don't know if password strength would be a 'cross-cutting concern' > as it only applies to a small number of classes - Users mainly. > > Brian Kotek commented somewhere recently on a UPS parcel object that knew how > to reach its destination - basing the journey on cost, time factors etc. > If a UPS object is doing all this surely our humble User should be able to > check his/her password is strong? > > I do accept though that checking that newPassword equals confirmNewPassword > MAY be something that lives outside a User. > But again, just because we don't persist the 'confirmNewPassword' who's to > say that it shouldn't live in the Model because all View's would probably > implement a password change in the same way (ie have existing, new and a > confirm field) > > Alan > > ----- Original Message ---- > From: Brian Sadler <[EMAIL PROTECTED]> > To: CFCDev <[email protected]> > Sent: Wednesday, October 22, 2008 5:04:56 PM > Subject: [CFCDEV] Re: User password changes and OO confusion > > Hi Alan, > > I agree with Tom that option c is definitely the best one of the > three. The User object has one (and only one) password, it doesn't > make sense for it to have a newPassword, or confirmPassword fields as > well. > > Also I think Michael had a very valid point about the actual logic to > validate the password change being in a Password / Authentication > object as opposed to the User object. However the route to actually > calling that might be quite long – UserService.updatePassword() calls > User.updatePassword() which delegates to > Authentication.validatePasswordChange() etc. > > It also throws up the question of what you’re using the service layer > for because to my mind, people are using service layers in two > different ways: firstly, there’s the service layer as a facade for > coarse grained access to the model, and secondly there’s the AOP > approach of a service layer component providing services to the model > – I think “cross cutting concerns” is the appropriate phrase. > Security functions –isAdministrator(), decryptPassword() and > validateNewPassword() seem to me to be typical cross-cutting services > that you would provide to potentially many components in the model. > > So whilst I entirely agree with your point about not wanting to have > anaemic domain models with all the logic stuffed in the service layer > (facade) I think in this case the service layer (AOP/cross cutter) is > the appropriate place for making sure new password is of sufficient > length, complexity etc. etc. > > On Oct 20, 6:15 pm, Alan Livie <[EMAIL PROTECTED]> wrote: > > @Paul, @Matt - thanks for this. Nice approaches. I see the cloning gets > > around the problem previously posted on this group about the session user > > in an invalid state. > > > Thanks > > > Alan > > > ----- Original Message ---- > > From: Paul Marcotte <[EMAIL PROTECTED]> > > To: [email protected] > > Sent: Monday, October 20, 2008 5:53:04 PM > > Subject: [CFCDEV] Re: User password changes and OO confusion > > > I'm with Matt on this. In fact I just wrote this up last night. Consider > > it a variation on a theme... > > > <cffunction name="changePassword" access="public" output="false" > > returntype="any"> > > <cfset var user = getCurrentUser().clone()> > > <cfset var result = getTransientFactory().create("ServiceResult")> > > <cfset var errors = StructNew()> > > <cfif hash(arguments.currentPassword) is user.getPassword()> > > <cfset > > result.setErrors(user.populate(argumentCollection=arguments))> > > <cfif (result.getSuccess())> > > <cfset result.setErrors(user.validate("changePassword"))> > > <cfif (result.getSuccess())> > > <cfset user = getUserGateway().save(user)> > > </cfif> > > </cfif> > > <cfelse> > > <cfset errors['badCredentials'] = "Password invalid."> > > <cfset result.setErrors(errors)> > > </cfif> > > <cfset result.setResult(user)> > > <cfreturn result> > > </cffunction> > > > On Mon, Oct 20, 2008 at 9:45 AM, Matt Quackenbush <[EMAIL PROTECTED]> wrote: > > > In my humble opinion, the User absolutely **should** know how to validate > > itself, including validating a new password. Otherwise, exactly as you've > > suggested, you end up with a bunch of bloated structs called CFCs floating > > around your application. > > > Like anything, there is more than one way to skin a cat, but here's a bit > > of pseudo code from my controller that shows how I handle a password change. > > > user = getSecurityService().getSessionUser(); > > if ( user.isPassword( event.getValue("currentPassword") ) { > > clone = user.clone(); > > clone.setPassword( event.getValue("password") ); > > clone.setConfirmPassword( event.getValue("confirmPassword") ); > > > if ( clone.validate( context: "change password" ) { > > clone.save(); > > } else { > > // send them back to the form with validation error message(s) > > } > > } > > > HTH > > > On Mon, Oct 20, 2008 at 10:26 AM, Alan Livie <[EMAIL PROTECTED]> wrote: > > > I keep falling into the 'anemic domain model' trap and for once I want this > > User to be a genius :-) I have too many simple beans with dumb getters and > > setters and service methods with all the good stuff. > > It must end! > > > As far as my User goes, it can be in an invalid state until the save() > > method calls validate() before persisting the data if validation passes. So > > the User can have an invalid email address until validate() is called. > > > Alan > > > -- > > Paul Marcotte > > Fancy Bread - in the heart or in the head?http://www.fancybread.com > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection > > aroundhttp://mail.yahoo.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 -~----------~----~----~----~------~----~------~--~---
