In the project I am working on at the minute I have created a base_service.cfc that provides an init() constructor function which works in exactly this way.
This works well for the application I am working on right now, but I would hesitate to put too many rules about how to implement things because it reduces the flexibility of the system to accommodate project specific requirements. The rules are essentially as follows: (Bearing in mind that rules can and probably should be broken if they cause more pain than they remove for any given project) All data validation is done in the model layer. All persistent data accesss such as databases, file systems, external systems is done in the model layer. Neither the Model nor the Presenter layer ever directly generate output for the user. The only layer that ever creates output is the view layer. The logic for what to display for any given URL is contained entirely in the Presentation layer. The presentation layer CFCs will call methods in the Model and call custom tags in the View to generate the output (normally HTML). The Model never calls the View layer directly, and the View layer never calls the Model layer directly. The only type of logic in the View layer is a boolean test to see whether or not to display something like a widget based on attributes passed into the custom tag. The View layer never interacts with any scope. (For my current project I am breaking this rule because I have to pass too many attributes that are effectively constants for the lifetime of a request. I have created a contextparams structure in the Request scope that contains many of the attributes I would have to pass otherwise. I am currently considering whether or not I should keep this as a standard for all future Batfink projects.) All exceptions in the Model are rethrown and dealt with in the Presentation layer. The model may perform some additional processing such as checking for data integrity, or writing a log, before rethrowing, but the Presentation layer contains the logic to know how to deal with exceptions. There are quite a few more, but hopefully you get the idea that the rules are more generic concepts than specific coding guidelines. For any given project there will be specific coding guidelines, project specific rules and possibly modifications to the existing rules. The standard Batfink rules give you a good starting point for structuring your code and approach to application development, but they are designed so as not to take away the 'fun' of figuring out what's the best approach for the project at hand. Essentially I feel that there is no single 'best way' to approach any project, so Batfink needs to be flexible enough to accommodate the specifics of each project, but structured and light enough to cut down the cost of development and more importantly maintenance. Spike >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of >Pat Branley >Sent: Monday, March 01, 2004 9:38 PM >To: CFAussie Mailing List >Subject: [cfaussie] Re: BatFink Released... > >Just a suggestion - maybe some of this is usefull - and this >is something were working on here at the moment with our CFC's > >each model cfc extends a base configurable.cfc > >Configurable.cfc contains: > >variables.config >setConfig( Struct conf ) >getConfig(): Struct >init( Struct config ) >onInit() > >I guess you could implement the same functionality without >using inheritance too. > >the idea being when you create objects you pass in the config >struct to the cfc that lives in the application scope. then if >that CFC happens to use composition and requires the same set >of config params (DSN being the most common use, but file >paths are another) the onInit() function creates the >components that live inside the orginal and pass on the config >as set by the application. > >Pat > > > >"Stephen Milligan" <[EMAIL PROTECTED]> wrote in message >news:[EMAIL PROTECTED] >> >> As a rule model components do not interact with any scopes. >> >> There are two places in the wiki where cfcs from the model read the >> data storage directory from the application scope. Treat those two >> occurrences >as >> bugs in the way the wiki was coded. The storage directory should be >> explicitly passed into either a constructor init() function, or to >> each function that needs to use it. >> >> I have toyed with the idea of creating a set of 'constants' in the >> application scope that can be read by any component, but so far I >> haven't really needed to do that. Until I find a case where >it really >> causes more problems to pass variables than to access them >directly I >> expect I'll continue to keep the model layer unaware of any scopes. >> >> Spike >> >> >> >> >-----Original Message----- >> >From: [EMAIL PROTECTED] >> >[mailto:[EMAIL PROTECTED] On Behalf Of Pat >> >Branley >> >Sent: Monday, March 01, 2004 5:55 PM >> >To: CFAussie Mailing List >> >Subject: [cfaussie] Re: BatFink Released... >> > >> >Just having a bit of a look at batfink and one thing that >ive noticed >> >is that the model components intereact with the application scope. >> > >> >How does this work from flash ? I was under the impression that you >> >should never reference any external scopes in CFC's incase you may >> >one day want to reference them from a webservice or a flash movie ? >> > >> >Pat >> > >> > >> > >> > >> > >> >"Scott Barnes" <[EMAIL PROTECTED]> wrote in message >> >news:[EMAIL PROTECTED] >> >> >> >> >> >> Heyas >> >> >> >> As most of you probably know, we here up Tourism Queensland >> >eCommerce >> >> Dept, have been using a framework called "BatFink". >> >> >> >> Spike, the beer-o-matic himself is the core brains behind >> >this puppy, >> >> but none the less, most of us understand it, but yeah, >download it, >> >> play with it, tell us it sux, tell us it rox, either way >> >we'd love to >> >> see how your initial reaction to it is. >> >> >> >> http://www.mossyblog.com/batfink10.zip >> >> >> >> Its a self-documenting WIKI (well not as hardcore on the >docs part, >> >> but its enough to get you started). Its based on the MVP >> >pattern aswell. >> >> >> >> Now go play, thats an order... now MUSH MAGGOTS! >> >> >> >> -- >> >> >> >> Regards, >> >> Scott Barnes >> >> - >> >> http://www.mossyblog.com >> >> http://www.bestrates.com.au >> >> >> >> >> >> >> > >> > >> > >> >--- >> >You are currently subscribed to cfaussie as: >> >[EMAIL PROTECTED] To unsubscribe send a blank email to >> >[EMAIL PROTECTED] >> > >> >MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia >> >http://www.mxdu.com/ + 24-25 February, 2004 >> >> >> > > > >--- >You are currently subscribed to cfaussie as: >[EMAIL PROTECTED] To unsubscribe send a blank email to >[EMAIL PROTECTED] > >MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia >http://www.mxdu.com/ + 24-25 February, 2004 --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004
