Other than a few little tweaks (listed below), this is very similar to the mechanism I use, so I'd say it's a good one. ;)
First off, you can use the isQuery() BIF to detect if you parameter is a query with a lot more reliability than using the second parameter that has to be manually set. Second, I wouldn't skip validation just because it's a query. The point of abstracting all you business rules into a different area from your controller and presentation logic is so that they don't depend on eachother. By assuming that anything passed into your business logic as a query doesn't need validation, you're making a totally unenforced and very subtle link between the different parts that is bound to come back and byte you in the end. A better way to go, if you really need the ability to skip validation, would be to use a boolean parameter that indicates whether to perform validation or just blindly accept the passed data. So your method would be setObjectByStruct(struct, skipValidation), where 'struct' can be a struct or query, and 'skipValidation' would be an optional boolean that defaults to 'false'. Finally, you'll generally make your CFC easier to work with if you can get a list of all validation errors at once, rather than only a single error at a time. Specifically this is helpful for user interaction, because users would rather get a list of all the problems with their submission, rather than one problem at a time. So instead of setError() and getError(), you'd probably have setError() and getErrors() (notice the 's'), where setError() would be [potentially] called multiple times and getErrors() would return an array of errors. From the last sentance of the error-related paragraph, you might already be doing this. cheers, barneyb On Sat, 20 Nov 2004 15:27:32 +0100, Magnus Wege <[EMAIL PROTECTED]> wrote: > Hi everyone, > > I am using the Fusebox 4 framework with CFCs (my company doesn't want to use > mach-ii by now) and still quite new to the OOP approach. > > My Validation process initiates each time I call my setter-methods in the > CFC. Usually the validation processes when I call the method > setObjectByStruct(struct). > > The argument struct can then be a query or attributes from a form. Data > coming from the query doesn't need to be validated so the > setObjectByStruct(struct,structtype) is given the optional argument > structtype. This argument initiates the validation before setting the data > to the CFC's property (<cfif structtype neq "query">...do > validation...</cfif>). > > If an error occurred during the validation process the CFC's method > setError(datafield, message) is called. Through the getError() method I can > then check for errors and output some kind of message to the user. > > What are your opinions about this validation process? > > Greetings > > Magnus -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/blog/ ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at [EMAIL PROTECTED]
