FourQ and Batfink have absolutely no relationship to each other apart from the fact that I was involved in some of the development of FourQ and I developed Batfink.
What happens in FourQ might be compared to cfinsert and cfupdate, but Batfink doesn't require or exclude you from using a FourQ style of system if you wish. What Batfink attempts to do is to give you a good set of rules/guidelines to allow you to know where the logic for any part of your application should live. In the case of FourQ, that logic would live in the persistence CFCs in the model directory. For what it's worth my approach is as follows: I normally prototype out some of the base functionality of an application before trying to figure out too many of the implementation details. When doing this I tend to put all the model logic in the service CFCs including data validation and persistence. The main reason for prototyping the app is that I can get a good 'feel' for the application requirements before making too much of a commitment to any architectural decisions. Once I am satisfied that my approach for the prototype will allow me to move forward and build the whole application I update any documentation and start to nail down any specific coding guidelines for that app. Batfink takes a lot of work out of the process for me because I have a structured way to organize the logic for my application. If I need to have validation to check if a username alerady exists in the database I have a standard way to handle that. If an unhandled exception occurs I know exactly where to put the code to generate the user friendly error message, and I have a standard way to create different messages for different types of exceptions. I know that I only need one getUser() method in the model and I know exactly where that method will live. I also know exactly which template will contain the query that gets the user data from the database and I know that it is very unlikely that someone else will create another query to retrieve a user in a different component. If I need to implement security for any given method in the model I have a well defined place to put that logic and another well defined place to put the user friendly error message. The net result is that it is quicker to build apps and quicker to maintain apps than any system I have used before. That's not to say that it's perfect, but then again if it was I wouldn't be sending emails to the list, I'd be sipping coctails somewhere in the sun ;) Spioke >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of >Taco Fleur >Sent: Tuesday, March 02, 2004 2:18 PM >To: CFAussie Mailing List >Subject: [cfaussie] Re: BatFink Released... > >I got a few questions, stupid ones maybe ;-)) But there are no >doco's (at least that I could find) > >I had a quick/brief look at FourQ and batfink > >- is what your doing comparable to <cfinsert> and <cfupdate>? >As I said I did not have a detailed look but just flicked >through the pages, and it looked like it performed the same >functionality as the CF tags. >- what are the benefits of accessing the data this way? >- is it secure, I see a few preserveSingleQuotes used, not >sure if the data is filtered for any potential danger before >it reaches the query? > > >Taco Fleur >07 3535 5072 >Blog: http://www.tacofleur.com/index/blog/ >Methodology: http://www.tacofleur.com/index/methodology/ >Tell me and I will forget >Show me and I will remember >Teach me and I will learn > > >-----Original Message----- >From: Stephen Milligan [mailto:[EMAIL PROTECTED] >Sent: Wednesday, 3 March 2004 3:20 AM >To: CFAussie Mailing List >Subject: [cfaussie] Re: BatFink Released... > > >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 > >--- >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
