what I describe is still exactly how I'd do it. Imagine this: all of
your objects iherit from a master object that looks at a structure in
the private "variables" scope any time you set a property with the
setProp() method to see whether or not validation rules are defined for
the property you are trying to set. When the page with your form loads,
if there isn't a "Classmates" object in memory, it creates one. The
Classmates object inherits from that masterr object. Before loading the
form, if the form scope is populated then youloop over it and call
setProp() on the Classmates object to set all of the properties.
Afterwards, but also before loading the form, you call the validate()
method on the Classmates object and if it fails you pop-up the current
validation message. You then display the form - calling getProp() on
the Classmates object to prefill each form field. In the event that the
validation passed you could obviously show a success message, redirect,
or whatever. I've written a generic validation object that does all of
this, along with a simple way to define the validation rules in any
object that inherits from it. I've also written a custom tag that you
can pass any object to and it will validate the object and do a
javascript alert if there's a validation error. This approach has
allowed me to take a code base that was 2 years in the works before I
came to work here, and immediately enforce validation and private
variable scoping in all of the objects that make up it's business layer,
which is fairly large.
~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
Dawson, Michael wrote:
Maybe I wasn't clear enough of my reasons to extend a base validator
object.
I have a form for Classmates. I have a form data validator object
"ClassmateFormValidator". In that object, I have a single validate()
method that tests all the values.
In the validator object, I also have some common functions, that are
*not* related to the actual validation. These methods are: hasErrors()
and getErrors()
Note that these return information about the validation process. They
do not actually perform validation.
Ergo, I have a base validator object named "BaseFormValidator". It has
two methods: hasErrors() and getErrors()
My "ClassmateFormValidator" merely extends "BaseFormValidator", not for
code reuse, but because ClassmateFormValidator "is-a" BaseFormValidator.
Has this changed any perspectives on this issue? I fully understand the
wrongness of using extends for code reuse. I'm not really looking for
any code reuse solution here. However, the BaseFormValidator provides
some base functionality that is used by its children.
Thanks
M!ke
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Simon Horwith
Sent: Tuesday, March 08, 2005 3:08 PM
To: [email protected]
Subject: Re: [CFCDev] Is Decorator What I Need or Just Extends?
I suggest writing some generic validation routines in a base class that
all of your other objects extend. The application I'm currently working
on has a base class with methods for setting, getting, and validating
any property... written in such a way that every object is able to store
all data privately, define it's own validation rules, and define what
properties are and are not publicly gettable or settable. A decorator
pattern would be overkill for what you describe.
~Simon
----------------------------------------------------------
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]
