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: [email protected]
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 [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]
