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/
