I know how you feel ... 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 do something similar to this in most cases, loosely typing the getters and setters, since there is really no such thing as a typed variable in a web form anyway (they are all strings, even if it looks like a date or a number). This let's me place all the validation in one place, usually within the bean itself. If the time comes where it makes sense to abstract validation to a UserValidator, then it's pretty simple to refactor your app to do so. But for me, i usually find it easier to place a validate() function in the bean itself. Why shouldn't a user know how to validate it's own data? And if you have a special case, yes, you can place a validateAdminUser() method in your User bean. And if one day i'm such an experienced architect that i see the usefulness of creating separate validation objects, then i'll start doing that. I've tried it, and i actually like doing it that way too. I only have a slight preference toward less objects. When loading the form, the bean returns the values for all the fields, and any error messages or flags. Maybe you could try both approaches and see which you like better? 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]
