Peter, Nando & Cody,
Thanks so much for the ideas. It sounds like my
current implementation is somewhere in between Cody's and Peter's. I have
several lists (DisplayFieldList,RequiredFieldList,LengthFieldList,etc) all
stored in an XML file but do not hand off this info to a CFC for
processing. I have a CFC that stores the lists info, a udf to pull info
based on the field being checked but do this work inside a CFM file and not a
CFC. It sounds like I need to mirror Cody's implementation more a flush
our a framework approach for that aspect.
Regarding the XML storage files, do you open, read,
parse and pass the lists from the XML into the CFC doing the
validating on each request or do you try to persist the XML info and then
pass it in? Currently I'm persisting the XML but the final size
of the file could be rather large and I'm worried about the memory overhead on
the server when I have 30+ sites running at once. I'm weighing the
'persist in memory to make the request faster' versus the 'preserve server
memory and make the request slower' issue.
-Jason
P.S. Nando I use a bean but given some security issues only
portions of the bean might get populated. So validation depends on who is
logged in and what rights they posse, hence why I have choosen not to put the
validation into the bean b/c this is the part that changes and I'm trying to
'encapsulate what changes' and be a "good little OO programmer". :)
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Bell
Sent: Friday, June 09, 2006 2:10 PM
To: CFCDev@cfczone.org
Subject: RE: [CFCDev] Model or View?
Hi
Jason,
I
would take what Cody said and just expand on it a little.
Usually when you think about forms for editing objects, the most common
requirements are transformations, validations and calculations. Tranformation
might pull all the non-numerics from a phone field before a validation tests to
see if it has the right number of numeric characters, and you might have
calculations if you wanted to store total order amount based upon sum of order
items rather than calculating the field every time it was retrieved (horses for
courses).
In our
system we distinguish between entity/attribute level
transformations/validations/calculations and action specific
transformations/validations/calculations. It is a pretty easy distinction to
make. (To save typing I'm just going to consider
transformations - it's same for the other two). If a user email is
ALWAYS required (whether you're importing data, pulling it from a third party
service or filling out a form), there should be a ValidateUserEmail() that is
always run as part of the save process.
However, sometimes you have an action (what we call a specific facade
method in the controller that wraps the model - user login, add to cart, edit
pages, etc.) that has action specific validations. For instance, we have clients
who do have some user records without email addresses which we need to be able
to import and where admin users need the ability to add a user without an
email address, but they want all new registrations to require a new email
address. In that case, you have to relate the ValidateUserEmail() to the
appropriate action. We still put it within a ValidationService in the model
layer, but the call is passed from the controller which adds user email to the
list of fields to validate (kind of like what Cody does, we do a lot of
processing using FieldNameList, EditableFieldNameList, FieldNameValidationList,
etc. as they all allow us to very easily use business rules to change the
validations or fields processed just by adding, removing or reordering field
names in a list).
So,
short answer is I'd put it in the model, but distinguish between action specific
rules and rules that are inherent in the very nature of your business entities.
It becomes important when you have multiple ways for getting data into the
system and want to ensure you have the right
validations/transformations/calculations in the right place.
Best
Wishes,
Peter
Peter
---------------------------------------------------------------Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Daiger
Sent: Friday, June 09, 2006 12:16 PM
To: CFCDev@cfczone.org
Subject: [CFCDev] Model or View?This isn't CFC specific but I think this list is best suited to help answer my question. I'm working on an application (built using Fusebox 5) and am using FB5 as the MVC framework. I am placing as much of the business logic (i.e. Model) into CFC's as possible and keeping the View's 'clean' from any business logic. I say clean b/c a view is never "truly" business logic free. Simple example: email address is required to create a profile in the system (business rule) therefore place a red asterisk next to it on the data entry form. It's that form validation area I'm looking for some suggestions/guidance. Where do people place form specific validation, the Model or View? And by Form specific validation I'm specifically referring to required fields, checking field lengths, email address checks, etc.Side note, I may have sat through one to many of Ray Camden's classes on security and hence have become paranoid b/c I always check field lengths, required fields, etc on the server side, regardless of what is going on w/ the client side, just in case someone tried to save the HTML page locally, hack it up and see what happens if they repost it. Also, I understand that some other frameworks, such as Model Glue, encapsulate all form or url parameters into a special object and pass this into a CFC for processing and since FB5 does the same thing and places those items in the attributes scope I could pass that to a CFC for validation. However, that does not feel like a good idea and hence I'm looking for suggestions & opinions.Thanks,JasonJason DaigerPH: 410.480.8148 x301EML: [EMAIL PROTECTED]----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org ----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
