Scott
Here is my take.
First off, never hard code any variable values inside my applications
anymore. This, for me is a security issue. If someone, somehow manages to
hack into your system, and gets a hold of your files, bye bye database. All
my environment variables get pulled from a database now, and populate the
variables they need to. I am now more utilizing the APPLICATION scope with
my apps, but not calling them directly. I duplicatte them into the request
scope and access them that way.
The way I see it, if your going to start to have your CFCs being accessed as
web services, then you are going to have to do either 1 of 2 things.
1) Hard code any reference to datasources, username and passwords into your
CFCs
2) Only have CFCs that to not require the accessing of external variables.
The reason I say that is this. I personally do see the security logic in
having your CFCs off your site root (ie site/components), so you would have
to store them somewhere else, somewhere that is outside the application its
self. Becasue of this, when you call the CFC as a web service, there is no
way that the CFC knows where to get the variables it needs, unless it
inherits or calls another CFC to somehow gather the variables it needs to
run. Also using XML files to store the security information it needs and
loading it into the CFC I don't particuarly like. Not for the fact that
your loading an XML packet, more that you are storing that information in a
plain text format.
What I would be more likely to do would be this.
First off you have an application config CFC in each of your application.
Then where you keep all your CFC files, you have a CFC with initializes your
applications. So you would have something like
<cfscript>
intApplication = CreateObject("Component","appPath.intApplication");
</cfscript>
Then from here you can do lots of thing. Let look at 2 functions. inApp
and returnApp.
If you were calling it from within your application, you would call the
intApp function which would set up the application for your application
under a web app environment.
<cfscript>
intApplication.inApp();
</cfscript>
Now, if I had a web service, I would call the same CFC, but call the
returnApp function. This function would gather the application variables,
and return that structure to your CFC, and away you go. You then have
access to everything your web application would, including DSNs, usernames,
passwords and anything else you set.
<cfscript>
returnStruct = intApplication.returnApp();
</cfscript>
This way, you still have a central location to control and maintain your
environment, yet you are able to call it from anywhere.
You may think that your still relying on your presentation layer for this,
but your not. This CFC can be anywhere you like really, and can pass what
ever arguments you need to get the application set up.
This also means you can have a many to many relationship with that CFC,
rather than a many to one relationship as your method will.
What do you think?
Regards
Steve Onnis
Domain Concept Designs
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Scott
Barnes
Sent: Wednesday, 12 March 2003 11:00 PM
To: CFAussie Mailing List
Subject: [cfaussie] CFC Concept Slinging .. You know you wanna be the
CFC monkey!
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/
---
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/
