> >>> The value is when you have different requirements depending >on which form was submitted. > >ah ha. Part of the difference is that we're calling straight >methods using form elements for values as whereas you're >setting properties. Until CF develops a decient cfproperty, we >won't bother with going nuts with setters and getters FOR >EXACTLY THIS REASON - lack of built-in data validation when >setting a property. CFMX != VB.NET
This difference isn't coming across to me very clearly. What do you mean when you way "we're calling straight methods using form elements for values"? > >>> At user registration you perhaps don't care whether they >fill in an address, but when it comes time for them to upgrade >or otherwise modify their membership so you can send them >products, you really do care about the address data. > >for us, these would be two different requirements, two diff >methods called (at least as it appears to the public interface) Two different methods called on what? Which interface? > >>> It also comes back to the simple rules of reducing coupling >and increasing cohesion. Specifically increasing cohesion. > >you're tightly coupling the val obj to the form, yes? isn't it >really to be used by the BO method? what interface are you >wanting to abstract? What do you think is the "val obj"? What do you mean when you say "isn't it really to be used by the BO method"? What reference to interfaces are you talking about? > >>> The validation object does one thing and one thing only. It >validates the input to a specific form. > >that's where our viewpoints differ. our app see the form as >merely a container. the UI elements validate themselves and >are then assigned as arguments to the method call. There *is* >a client-side "kernel" controlling the form (not submitting >without all required UI elements are valid). What is the form a container for? How do the UI elements validate themselves? How do you assign UI elemets as arguments to the method call? What sort of kernel are you talking about? > > >>> If you add a field to that form, you only have to add >another method to the validation object and call it from the >validate() method. > >for us, that validation method is rolled into the UI control. You mean JavaScript... Right? Presumably this means that JavaScript is a requirement for your application to work. If that's the case then there's a whole world of other things that are going to affect how you design and build the application, but you'd still probably want a back-end system to ensure that somebody hasn't circumvented your JavaScript validation. > >>> I'm not really sure what you're talking about here, but I >assume that you mean that this is providing some sort of >validation via the cfargument tag. > >no, before that. When the page loads, each UI element >registers itself against a "page manifest" (a js array). When >the form submits, each element is interagated to see whether >it's validation worked. if they're all OK, the form submits. > Yeah, that's still assuming that no-one's actually trying to break your system. All modern browsers have a facility to turn off JavaScript. If you want to build an application that's going to be robust in the face of users who want to break the system you're going to need to do something in the back-end too. The general wisdom is to always build the back-end so it won't fail and add JavaScript validation as a secondary consideration. That may not be the requirement in your case, but it's the general assumption I take to all web based apps. Regards Spike ---------------------------------------------------------- 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]
