Client-side validation is a user-interface concern, because it makes the user interface "nicer", as it doesn't force a server trip for common validation issues. It should NEVER be relied upon for any part of you application. Given a choice, I don't even use client-side validation until the app is finished. It just gets in the way and potentially hides problems with the app itself.
The two filters you mention populate a DTO and validate it. The DTO is then passed to your business layer and used to populate a BO, where it is validated again. The DTO validation (from ValidateFormObject) checks things like "date of birth (DOB) is a date in the past", or "Username isn't blank". This is stuff that has nothing to do with the business rules of you application, but with whether the data reasonable or not. Syntactic, not semantic. The BO validation (from somewhere in your backend, long after everything Mach-II related has been left behind) is about the semantics for your particular application. the DOB field probably doesn't need any more checking, but the username might need to be checked for minimum and/or maximum length, and definitely whether it's unique or not. Your DTO should have every setter using 'string' as the argument type, because that's what every form variable is. Your BO, on the other hand, should have appropriate types. For example, the DOB field would be of type 'date'. This quickly demonstrates the need for two-stage validation, because the form field for DOB could happily contain "tee-hee", which would cause the setter on the BO to fail (because it's not a date). On a bit of a divergent topic, Mach-II is a framework for building UI controllers. It's not a full-fledged application framework, and it's not designed to be. (The exact same thing could be said about Fusebox, but FB does provide a means to use it as a full-app framework.) Mach-II delegates to you listeners, and they delegate to your actual business components. You should be able to remove all the Mach-II code, and replace it with something else (Fusebox, standalone templates, Flash RIA, whatever), without having to rewrite any of your business logic. If you have to rewrite any of it, then it's in the wrong place. I'm not suggesting that you attempt this without need, but it's a great mental exercise that I use all the time. Does this have to do with user interaction, or does it have to do with the application's business functionality? NOTHING has to do with both. If you think something does, then you haven't broken it down into small enough pieces. cheers, barneyb On Tue, 2 Nov 2004 10:09:28 -0800, Phil Cruz <[EMAIL PROTECTED]> wrote: > On Tue, 2 Nov 2004 09:36:55 -0800, Barney Boisvert <[EMAIL PROTECTED]> wrote: > > As I see it (certainly up for debate), there are two different > > situations regarding BOs and validation (matching your two > > alternatives). > > ...snip... > > > > One thing to keep in mind is that you need to make sure you're > > enforcing BUSINESS validation in your BO, not input validation, which > > should be enforced long before any data gets to your business layer. > > > > cheers, > > barneyb > > > > Interesting. Could you elaborate a bit. I'm guessing you're thinking > something more than client-side javascript validation (since JS can be > disabled) but once it's server side it seems like it gets into the > business layer pretty quickly. In Mach-II, there is an > EventBeanFilter that will take a bunch of form fields and use it to > populate a bean. There is also a ValidateFormObject filter that will > then call a validate() method on the bean. Is this counter to what > you are saying? > > -Phil > -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/blog/ I currently have 0 GMail invites for the taking ---------------------------------------------------------- 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 www.mail-archive.com/[EMAIL PROTECTED]
