I really need to blog on this, but consider writing a lightweight
generator that will turn the XML config files into generated classes. Better
performance and a single button rebuild process. Generators are your
friend!
Best
Wishes,
Peter
Peter
---------------------------------------------------------------Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Daiger
Sent: Friday, June 09, 2006 3:22 PM
To: CFCDev@cfczone.org
Subject: RE: [CFCDev] Model or View?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.-JasonP.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---------------------------------------------------------------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
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
