For example;
<cffunction name="getData" access="public" output="false" returntype="struct" hint="Get data for a specific objectid and return as a structure, including array properties and typename.">
<cfargument name="objectid" type="uuid" required="true">
<cfargument name="dsn" type="string" required="false" default="#application.dsn#">
<cfargument name="dbowner" type="string" required="false" default="#ucase(application.dbowner)#">
<cfset stArgs = arguments> <!--- hack to make arguments available to included file --->
<cfinclude template="_fourq/getData.cfm">
<!--- TODO: create a request scope cache for this --->
<cfset this.bgetData = 1>
<cfreturn stObj>
</cffunction>
It might be worth having a look at the fourq.org pattern. Even if it's not something you want to implement -- having a look at the code might give you some ideas for your own development. The latest build is available... but rather than mucking with all that you can browse the code online with the code browser:
http://makeashorterlink.com/?D2A3129C3
-- geoff http://www.daemon.com.au/
Scott Barnes wrote:
Well in order for some concept slinging, I guess I should outlay my overall objective and theories and see what pans out from here? (Why is it when you lay out your theories / frustrations in grasping something that maybe trivial to others..feels like you are baring your soul to the world!)
Objective ~~~~~~~~~~~~~~~~~~~~~~~~~ The key objective is to allow not only allow any given "web-friendly" presentation layer to access my components, but also make most/some of my methods within the components accessible to webservice calls while making them as portable as possible.
Application.cfm vs Containers
~~~~~~~~~~~~~~~~~~~~~~~~~
I have sat down briefly today and weighed the consequences of relying on
application scopes within CFC's? An example is Datasource names and DSN
username/passwords within the CFQUERY / CFSTOREDPROC tags.
Pre-CFMX, I would typically set these variables within the application
scope, and make direct calls to these variables throughout my
application.
In CFMX, you could continue to this, but then the CFC's would rely on the presentation layer as its source for such variables (that or whatever you use as your root page context layer).
Instead of using such a method, I have thought of using a container that is extended by all "SQL" based components.
This then allows me to have the one cfc that can either have the DSN details hard coded within the init() method of that component OR it could even load the configuration from an XML packet via an argument I pass to the container instantiation call.
This would then take away the assumption factor but also allow for a central configuration file for server setup. Thus enabling WebServices to access the API calls to a component without having properties hard-coded to individual cfcs.
Your thoughts? Problems foreseen?
Business Logic that Extends to SQL Logic ~~~~~~~~~~~~~~~~~~~~~~~~~ I'll begin with an example of a situation where I have a "shopping cart" app. In this shopping cart application, I have a product.cfc and a productSQL.cfc
The product.cfc has the extends attribute that points to productSQL.cfc, which now allows me to access the four types of query based calls for all product logic (select, insert, update, delete) as well as have the ability to do non-sql based calls for the product logic all within the one "object" (i.e. application.product.yourMethods());
So when I instantiate the object "products" within the application scope, I would do this:
application.products = createObject("component","mypath.products");
Which basically follows the object inheritance relationship to this:
Products.cfc > productsSQL.cfc > AppContainer.cfc
Now the relationships in this concept seems to me "clucky" and untidy, but hopefully you can see the thought process I use in modelling the components so that they can all be housed in the one funky container.
In doing this, I can then apply this same concept to other models, such as "Customer" object (which would be customers.cfc > customerSQL.cfc > AppContainer.cfc)
My question to the CFC gurus out there is, how do you separate the Database layer from the rest of the business logic? So that if the evil IT Dictator walks into your cubicle and demands you halt all SQL interactions and go forth into the dark realm of ORACLE, it in a nutshell shouldn't be as big of a hassle as it would have in CF5.0 or earlier.
Furthermore, what are your inheritance/relationships between the DB Logic and your business logic? (once again sorry for the over-use of buzz words like "logic").
A Webservices Container? ~~~~~~~~~~~~~~~~~~~~~~~~~ In using this style of development, I then could create a webservices.cfc which has the following as an Init() method
<cffunction.. init()> <cfscript> this.products = createObject("component","myPath.products"); this.customers = createObject("component","myPath.customers"); this.monkeys = createObject("component","myPath.monkeys"); </cfscript> </cffunction>
Its really just an empty pointer in many ways, but it will allow the public out there to make webservice calls to the one URL (http://www.mydomain.com/webservices.cfc?wsdl) that in return can have access to heaps of methods via the one spot.
Ie. Webservices.products.getAllProducts(); Webservices.customers.getAllCustomers(); Webservices.monkeys.setAllMonkeysMode(spank);
Cacth 22, is that the appContainer.cfc properties are placed inside each component (ie 3 times) Which once again seems untidy and leaves a bad taste in ones mouth? I could do test statements to see if the dsn details etc already exist etc..
Summary
~~~~~~~~~~~~~~~~~~~~~~~~~ I'm excited that CFCs opened up lots of fun ways to develop by, but like
many of the other CFC gits out there, we are left with a point of no
return in that.. what do I do, how do I do it.. wheres that firkin rule
book and where who what and when's leave me confused, wet and tired :D
In truth I can see why patterns like FuseBox took off in the pre-CFMX days, as it was a rulebook people could turn to and go "ahh, if I follow this style, I'll be like all the other sheep in that following a set path and hoping for the best"
It's a copout I know, but I'm wanting a tight/clean way of doing development.
Scott Barnes Snr Developer
eCommerce Department
Tourism Queensland / Sunlover Holidays
[EMAIL PROTECTED]
ph: (07) 3535 5066
--- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED]
MX Downunder AsiaPac DevCon - http://mxdu.com/
