Hi Jason, Just skimmed this, and I have no real FB experience, but one possible solution might to have a base validation.cfc in a shared directory and to have project specific validation.cfc's that extend the base validation.cfc so you only have to put any project specific code into the individual validation.cfc's. There are limitations with this approach including the fact that if your validations inherit from this they can't inherit from anything else and the fact that inheritence usually isn't a best "first choice" for solving a problem, but it is one way to go . . . It is somewhat similar to what Reactor does where is generates editable UserGateway that extends the generated UserGateway to allow for round trip generation by having custom code and generated code in different files and can be a neat solution in certain situations.
Best Wishes, Peter -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Daiger Sent: Thursday, June 01, 2006 10:32 AM To: CFCDev@cfczone.org Subject: [CFCDev] Encapsulating what changes I have an form input intensive application that I would like to encapsulate the validation rules into a CFC. This application is used and 'tweaked' for 40+ different clients each year using XML configuration files to store things such as field labels, field required lists & security rights . If the client has a business rule the configuration file can't handle, then the validation code for the form must be changed. It's really a 90/10 rule where only 10 percent of the clients require such a change but we must design the system to support that 10%. Therefore I'm looking for a way to easily alter a validation CFC. Seems easy enough but I use strict typing, e.g. com.attendeeinteractive.aievolution.v100.Person, and want to continue this practice. I've thought about a Factory object that would accept an optional project code and then return the proper CFC to the caller. However, this seems like my Factory object will eventually get bogged down with lots coding changes and ultimately result in a big switch statement. That solution just does not seem like a good one to me. Any other suggestions out there? As an FYI, we are currently using Fusebox 5 and have put this form validation code in a CFM file w/in a circuit. So changing the validation rules is easy. Copy the 'offending' circuit out to a custom directory, altering the FB 5 XML file to point to the new circuit, edit the CFM file and we're done. Works great for now but down the road if I want to add a new front end, such as Flex, it's not going to work b/w it's a framework specific solution. So I would like to put the validation rules into a CFC to give me the option later of adding a new front end without editing the server side business rules. That's my goal and any help or suggestions on reaching that goal would be appreciated. -Jason -- Jason Daiger URL: www.jdaiger.com EML: [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
