Barry Beattie wrote:
Nando, here's a "Dorathy Dix" question for ya:
is the bean part of the view or the model?
why?
if you had multiple messages to return should you put a "<br />" between them?
This kind of question would have really thrown me until a week or so
ago. I watched the movie "What the bleep do we know" and came to the
conclusion that there are many similarities between OO design and
quantum physics.
In other words, according to quantum OO theory, the break tag can be in
2 places at once, in the model and in the view. I know it's baffling
how that could be the case. It certainly defies our everyday experience
of things being in only one place at a time. But that's quantum OO for
ya! ;-)
would you CFTHROW to pass the message (and if so, when if there
multiple things wrong) or return the message after skipping over the
action with a big "IF" ?
(I know what I'd do but I'm curious how you or others would aproach it)
I'm currently running a validate() method in the bean itself. Seems
easier to me so far to keep it in the bean rather than adding a
Validate object.
Validate() checks for missing fields and adds their names to a list in
variables scope. Same with invalid fields. If something's not valid,
validate() returns false. And then getValidationResult() is called on
the bean, which returns a structure with keys for each field i'm
validating. Inside the key is placed the result. This could of course
be reworked for custom messages for each field i'm validating, but i'm
happy to just give the user a generic "Please fill in the missing
fields indicated in red below."
I don't set the message in the bean, by the way. I just indicate
whether to display it or not. We use multiple languages in our views.
<cfif Len(getMissingFields())>
<cfloop index="key" list="#getMissingFields()#">
<cfset val[key] = "missing" />
</cfloop>
<cfset val.displayMissingMessage = true />
<cfset val.isValid = false />
</cfif>
<cfif Len(getInvalidFields())>
<cfloop index="key" list="#getInvalidFields()#">
<cfset val[key] = "invalid" />
</cfloop>
<cfset val.displayInvalidMessage = true />
<cfset val.isValid = false />
</cfif>
In the display, i've got something like this:
<div class="label#val.firstName#">First Name</div>
and in the stylesheet,
div.labelmissing {color:red
div.labelinvalid {color:violet
Could be done better, i'm sure, but that's all the quantum OO my simple
mind can manage to deal with at this point.
;-) n.
barry.b
On 3/31/06, Nando <[EMAIL PROTECTED]> wrote:
I have a form, that is populated by a bean, which updates the bean
when the form values are submitted. The update is done very simply
using cfset my.setMemento(#form#).
My question now is how do I error check and make the error message
something useful to the user. If a user enters a non numeric value
into a numeric form field that tries to update the bean, an error is
thrown like:
A form field is always a string, so your bean should accept only strings. Once bean is updated with the values from the form, then you can validate a particular field however needed.
The value returned from function getNumberValue() is not of type numeric.
I am using http://rooibos.maestropublishing.com/ to generate the bean
and there is an option for validating.
I also understand that I could create a cfc that would pass the values
to the bean, check for errors and return messages in a more manual
way, but the setMemento is so easy, If I could figure out error
checking also, it would save me alot of time in future projects.
I suppose validation will always have some custom elements to it. One of the things i really "hate" when people design validation systems is they don't take the perspective of the user. I happen to live in Europe and i've often run afoul of validation routines in websites, (Adobe's support site was the latest) that were simply unnecessary. The area code in my phone number has 2 digits. But the programmer who designed Adobe's support website assumed that all area codes everywhere must have 3 digits, or it's not a real phone number.
Ironically, i had to submit a fake phone number so it would be "valid".
I've also seen programmers validate a phone number field as numeric, because it's a phone number, but what happens when you have an extension and can't enter it?
I've also seen programmers assume that a phone number is number that has 10 digits, and cannot begin with a 0.
The bottom line here is you can't force a person to give you their real phone number or a real email address with "validation" - that strategy may even backfire. And even in the case of required fields ... my stance here from a usability perspective is to leave it as open as possible. If someone just wants to leave you their email address and a first name and not their phone number, street address, date of birth and mother's maiden name, fine. Let them leave the information they want to leave. In my opinion, a form is much more "usable" if it lets me fill in what i want.
Of course, some business rules will insist that certain fields are required. But then they generally will make sense to the user. You can't have an application to apply for a copy of your birth certificate where first name, last name and mother's maiden name are optional.
If for some reason your program needs the data in a certain type (say you need room numbers numerically sortable - i just ran into that yesterday) - I still wouldn't validate that room number field as numeric! I'd let users enter their valid data, even the ones who have room numbers 2A, 2B, and 3C ... and figure out how to deal with that within the program itself.
There. Now i've saved you a lot of time in your future projects with my simple plea. Validate sparingly! Let me enter my real phone number, billing address, and zip code once in awhile.
;-)
ciao,
Nando
TIA,
--
David Mineer Jr
---------------------
The critical ingredient is getting off your butt and doing
something. It's as simple as that. A lot of people have ideas,
but there are few who decide to do something about them now.
Not tomorrow. Not next week. But today. The true entrepreneur
is a doer.
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
--
Aria Media Sagl
CP 234
6934 Bioggio
Switzerland
www.aria-media.com
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
|
