I have not ran into this but perhaps it is the fact that I do my validation
via the my validator object that is outside of the beans and I have some
if/else logic in the calls to that, but offhand can not think of an example
where I have done that. This is more for the simple CRUD stuff that is so
mind numbing to create and maintain, not more complex though it could be
ported to that to some extent I suppose.
I know on one of my patient management screens we collect SSN but only
administrators can see those or edit those after the initial insertion. Now
the actual system just runs the validation on the preexisting ssn but it
could have been done with an "if" statement on the call to the validator
object for that "setter" would be something like:
if(useraccess is "admin") { objValidator.Setvalue("ssn", ssnvalue); }
The way my system works is after the sets(zero or more) have been ran in a
bean object and no errors were found then it is fed into an object I use
that builds the insert/update queries based upon what was set and what the
database requires. So in the example of the SSN if I just bypassed the
setter when not an administrator the update query that would get built would
never reset its value.
Guess it also depends on what one means by "validating" because I actually
have several layers, what is done in the bean/validator is more for the last
resort server side validation when a form is submitted. The checks to make
sure dates are dates and not just random text or numbers are numbers and so
on. It just allows for presenting a well formed error message to the user
if they managed to bypass everything else and it requires little effort to
make since most of it is automated down to the generation of the beans.
I actually used to not even use beans for that. My object I use for
building the insert/update queries did this since it references the database
metadata anyway that has everything needed to know what needs to be done.
This has been an evolving system for awhile now, kind of a combination of
various tools and eventually will tie into our form maker. The original
system I actually preferred somewhat because this one means if the database
changes(which they do at times) then the bean needs to be edited, the old
setup since it worked 100% off meta data did not need that done. Example if
someone had the field for first names set to 50 characters then decided to
change that to 75 after the fact the old setup needed nothing done the
current one means editing the bean to take that into account.
On 2/28/07, Peter J. Farrell <[EMAIL PROTECTED]> wrote:
Aaron Rouse said the following on 2/28/2007 3:32 PM:
> I allow my beans to take in pretty much anything but then do checks in
> my Sets within that bean to validate the data. If the data is valid
> it sets it but if it is invalid it returns a error message that is put
> into an array of messages. Basically I initiate the bean and then a
> validating object, I use the validating object to run/set the setters
> in the bean. If the validating object gets something returned to it
> on any setter then it adds that message to its instance array for
> errors. After all of these sets I check for a length on that array
> and if something is found I halt the page and display those.
I've found that validating in my bean leads to cases where it's tempting
to use if/elseif's when you need an exception to the validation
"rules". I have since moved to validation methods in my service layer.
I have since leveraged this approach successfully since I can create
common validate blocks that can be used by other validation routines --
sometimes your user needs to be validated differently. For example,
people with admin rights get to break certain rules, while users editing
their own account adhere to strict validation. So that leads me to
validate() and validateByAdmin(). So I pass my bean to a method in my
service layer instead of making the bean self-validating. Personally,
self-validating beans are fine for when the system is simple, but as the
application evolves (which they all do) things always get more complex.
Just food for thought...but then again I'm usually building applications
with very complex business requirements.
Best,
.Peter
--
Peter J. Farrell - Maestro Publishing
http://blog.maestropublishing.com
--
Co-Host of the ColdFusion Weekly Podcast
http://www.coldfusionweekly.com
You are subscribed to cfcdev. To unsubscribe, please follow the
instructions at http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
--
Aaron Rouse
http://www.happyhacker.com/
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at
http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
