Simon, I'm curious as to how you
would structure a simple application where a form provides input that
is eventually stored in a database.
These are a couple of the plans
I have for such a solution:
Solution #1
Form page is loaded
If this is a new form entry, an
instance of a data bean is created and initialized with default/empty
properties.
If this is a modification of an
existing record, an instance of a data bean is created by a DAO object.
The data bean's getters are used
to populate the form fields.
The form is submitted to itself.
The form data is loaded into a
new instance of the data bean.
The bean is passed into a form
data validator object.
The validator's validate()
method is called.
Any errors are recorded in an
error handler object.
If errors are found, the data
bean's getters are used to populate the form fields, again.
If no errors are found, the data
bean is passed to the DAO for insert/update
Solution #2
Basically, the same as solution #1, but
without the separation of the data bean and the validator.
The validation is wrapped up in the data bean.
I know that doesn't follow the
best-practices, but, at this time, I don't see much need in having two
almost-identical objects. One with validation logic and one without.
Maybe I'm missing the point, but I need to start somewhere.
Thanks
MAD
I don't like this idea of "form validators". Validation by an object
should be performed on other objects. After all, data collected by a
form, if it's used for anything, should be stored in an object
somewhere. The data being collected via a form(s) is still being
validated either way, but validating forms and validating objects are
very different ideas in the context of the thought process behind how
to approach the requirements at hand.
~Simon
Simon Horwith
CIO, AboutWeb - http://www.aboutweb.com
Editor-in-Chief, ColdFusion Developers Journal
Member of Team Macromedia
Macromedia Certified Master Instructor
Blog - http://www.horwith.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 