>> 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
>> 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)
>> 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?
>> 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).
>> 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.
>> 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.
eg:
this is a (date) text box that sits within a more complicated UI control (so the
example is a bit messy but you get the idea - I gotta finish up and move on)
<control:textinput
id="#attributes.id#_textinput"
class="#attributes.class#"
fieldName="#attributes.fieldName#_textinput"
type="date"
value="="#attributes._textinput#"
editable="#attributes.editable#" <!--- T/F --->
length="#attributes.length#"
maxChars="#attributes.maxChars#"
enabled ="#attributes.enabled#" <!--- T/F --->
required ="#attributes.required#" <!--- T/F --->
validate ="#attributes.validate#" <!--- T/F --->
alt="#attributes.alt#"
/>
cheers
barry.b
--
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
----------------------------------------------------------
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]
