I allow my beans to take in pretty much anything but then do checks in my Sets within that bean to validate the data. If the data is valid it sets it but if it is invalid it returns a error message that is put into an array of messages. Basically I initiate the bean and then a validating object, I use the validating object to run/set the setters in the bean. If the validating object gets something returned to it on any setter then it adds that message to its instance array for errors. After all of these sets I check for a length on that array and if something is found I halt the page and display those.
On 2/28/07, Peter Bell <[EMAIL PROTECTED]> wrote:
Actually, I'd allow the user bean to be unfussy in terms of typing. I let my beans take any old input and then validate it before allowing it to be saved. I find that works better as I can keep all my user specific validation either in or composed via my user bean. Same for products, categories, pages, etc. I'd also call User.authenticate() which could then call the UserService to handle the authentication. It is just syntactic sugar rather than just saying UserService.authenticate(User), but I find it easier to keep my oo head on by using the User.authenticate() style syntax. Best Wishes, Peter On 2/28/07 3:42 PM, "Jaime Metcher" <[EMAIL PROTECTED]> wrote: > > "...ask the service for a User object, set the username and > password, then ask the object to validate the input?" > > FWIW, that's the way I do it. With the proviso that the User object is > allowed to be fussy about its inputs in terms of typing. So the view and > controller would handle the client and server side parts of ensuring that > required fields are completed, strings aren't too long, dates are real dates > etc. Then you instantiate a User object with those properties and ask it > questions like "Do you exist in the user database?" and "Are you > authenticated?" - which in the context of a login form could be thought of > as validation and would be reported to the user in a similar way. The > dividing line between these two kinds of validation is elastic (and > permeable!) - and if you're not attached to strong typing and therefore can > pass any old thing to your object, it's very elastic indeed. > > Jaime Metcher > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Paul > Marcotte > Sent: Thursday, 1 March 2007 5:24 AM > To: [email protected] > Subject: [CFCDEV] Where should I validate form submissions? > > > Hi all, > > I've gone over this and re-wrote my Controller three times now. I'm > looking for a best practice suggestion. > > My Coldsping managed, Service Layer pattern MVC app uses a Controller > that listens for a login action. The login form uses username/password > pair and I want to get into the habit of validating input prior to > authenticating the login credentials. > > In the spirit of keeping a Controller primarily logic free, I originally > requested a userId from my UserService passing in the form variables. If > the return value was not 0, I hit the Service again for a User instance > and then pass the instance on for the view to use. Using this method, I > could provide a response that the login is bad (0), but not if the > required form input is valid. > > After that, I tried having my UserService return either an object or an > array of errors (yikes!). > > Now, I'm validating the form variables in the Controller prior to > passing them to the UserService and it still feels fishy to me. > > What if I ask the service for a User object, set the username and > password, then ask the object to validate the input? If the input is > valid, I send the object back the Service for authentication. If > authenticated, carry on. If not authenticated, prepare an error message > and pass error to view for display. > > I'm modifying Illudium PU-36 generated CFCs for my model (stripping down > the validate() method into validatelogin()). > > Also, I plan to roll js validation on the front end as well, but I want > implement server side validation first. > > Paul Marcotte > BCJobs.ca > phone: (604) 684-5627 ext. 223 > e-mail: [EMAIL PROTECTED] > > > > You are subscribed to cfcdev. To unsubscribe, please follow the instructions > at http://www.cfczone.org/listserv.cfm > > CFCDev is supported by: > Katapult Media, Inc. > We are cool code geeks looking for fun projects to rock! > www.katapultmedia.com > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > > > > > You are subscribed to cfcdev. To unsubscribe, please follow the instructions > at http://www.cfczone.org/listserv.cfm > > CFCDev is supported by: > Katapult Media, Inc. > We are cool code geeks looking for fun projects to rock! > www.katapultmedia.com > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
-- Aaron Rouse http://www.happyhacker.com/ You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
