Morning Tom,
Thanks for the in-depth explanation on this stuff.
The bean method sounds quite intriguing and it's not one I had considered
before you mentioned it. Whilst this first form is nothing special, just a
basic contact form which allows the user to send us a sales enquiry, I'd
rather go for a method that I can expand on and use down the line, I'm not
one for cheating at this kind of thing :-D
Before you got back to me yesterday I played around with a stack of
different ideas, and at the moment my form process works something like
this.
I have 2 events, one to display the form, then another which processes the
form and posts the user to a 'thank you' view.
Now, in my controller for processing the form I have function called
'sendMail', and in here I have been doing validation on the fields, building
a structure of the error messages.
After validation, if the structCount() for errors is 0, then I post the
fields off in a mail using a mailer component, but if the structCount() is
GTE 1 then I place the errors into the ViewState, and I add a result like
ARGUMENTS.Event.addResult("ValidationError");
In my model-glue XML it is set to pass the user back to the form if the
result 'validationerror' is found. Then in the view I simply output the
error structure from the viewstate.
Now, whilst this works for me, I'm always looking to adopt the 'best
practice' type methods, so I'm keen to learn a little more about how exactly
I could implement your bean method.
I'd love to hear more,
Thanks Tom,
Rob
-----Original Message-----
From: Tom McNeer [mailto:[EMAIL PROTECTED]
Sent: 20 March 2007 17:54
To: CF-Talk
Subject: Re: Model-Glue Form Validation
I'd say the overall answer is the standby: "It depends."
There's nothing wrong with using the CFC you mentioned, if it still suits
your needs.
One of the frequently used features of Model-Glue (or Mach-II, for that
matter) is the ability to automagically populate a bean from a form
submission. This could be a bean you build yourself; or it could be
something like a Record object created by a framework like Reactor or
Transfer.
The bean encapsulates the form submission -- and most likely represents a
record headed for your database. You could then call methods in your
validation CFC and pass in getters from the bean, like
isEmail(bean.getEmail).
If the validations pass, you then use the bean to do whatever's next -- like
update the database.
Record objects created by the ORM frameworks often have their own validation
methods, which can be extended.
As far as when/where you do your validation -- strictly it should probably
be done within the model, in a business object of some kind. Your validation
rules may be more than just validating an e-mail address. They might involve
comparisons of two values from the form submission, or checking against some
other value. So they're really business rules.
On the other hand -- there's no big reason to complicate things either. If
all you're doing is basic stuff like validating e-mail addresses, whether or
not a value is numeric, and things like that, I don't think anyone will
shoot you for doing it within the controller.
As far as error handling goes, a typical scenario would be to create a
message based on the validation failure, stuff it into the event --
event.setValue("errorMessage"), then create a Result which would announce
the event calling the form page again.
--
Thanks,
Tom
Tom McNeer
MediumCool
http://www.mediumcool.com
1735 Johnson Road NE
Atlanta, GA 30306
404.589.0560
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Create robust enterprise, web RIAs.
Upgrade & integrate Adobe Coldfusion MX7 with Flex 2
http://www.adobe.com/products/coldfusion/flex2/?sdid=RVJP
Archive:
http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:273244
Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
