Hmmm.... controller level function...not for me, I'm afraid! :-)
I've been struggling for years to maintain a fusebox app (of FB3
vintage but migrated painfully to FB4 & 5) that has fat-controller-
itis precisely because stuff like this got stuffed into the
controller. Admittedly it was a lot harder to have lean controllers
back in the days of FB3 than it is now, but still...
As soon as you shove business logic or validation into the controller
you make it much harder to do things like switch frameworks, or target
a different presentation tier (Flash Flex etc.)
Isn't that verging on an anti-pattern
On Oct 20, 5:58 pm, "Barney Boisvert" <[EMAIL PROTECTED]> wrote:
> First off, validating the confirmation password is a controller-level
> function. The confirmPassword field should never get any lower than
> that. Second, revalidating the user's password is a controller-level
> action backed by your business tier. Very likely implemented as
> user.isPasswordValid(form.password). Finally, you have the password
> change request. So the controller should look roughly like this
> (error handling code omitted):
>
> <cfif form.newPassword EQ form.confirmPassword>
> <cfset activeUser = ... /> <!--- whatever this looks like --->
> <cfif activeUser.isPasswordValid(form.password)>
> <!--- set the user's password to form.newPassword --->
> </cfif>
> </cfif>
>
> Obviously you can package the bits of functionality however you want,
> but the confirm password construct is UI specific. If you're changing
> user passwords via a batch job you don't have confirmation passwords,
> so you business tier shouldn't know about it. Validating the current
> password is UI specific for exactly the same reason (in a
> non-interactive scenario, there's no way to do it). The only piece of
> functionality that is part of the business tier is updating the user's
> password, exactly like updating any other field on your user bean
> (though hopefully with an implicit salted hash in the mix somewhere).
> I've intentionally left that piece out of my example because there are
> myriad ways that might be accomplished:
>
> <cfset user.setPassword(form.newPassword) />
> <cfset user.save() />
>
> <cfset userService.updateUserPassword(user.id, form.newPassword) />
>
> <cfquery ... >update user set password = #form.newPassword# where id =
> #user.id#</cfquery>
>
> There are many others, of course, but that's a whole different debate.
>
> cheers,
> barneyb
>
>
>
> 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
>
> --
> Barney Boisvert
> [EMAIL PROTECTED]://www.barneyb.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
-~----------~----~----~----~------~----~------~--~---
