Stephan,
Stepping back a moment, your question reminds me of when i first started
using CFC's. The concept of encapsulation threw me ... half of me
listened to the advocacy behind OO principles floating, and thought "It
must be very good" - but i didn't have the experience to judge it for
myself. The other half wondered what the harm was of just accessing the
DSN directly from application or request scope, like i had always done
in my procedural code.
You can of course do this with CFC's - there's no direct "harm". From
within a CFC, you can access variables set in server, application,
session and request scope. Try a few experiments for yourself to see this.
BUT ... a lot of experienced people on the list here are going to
suggest, almost as if it were the most obvious thing in the world, not
to do that. They are using CFC's as an object oriented construct,
because they find that quite valuable. When you use a CFC as an OO
construct, as an object, you treat the CFC as encapsulated, it has a
fence around it and everything that happens outside the CFC doesn't
affect anything inside the CFC, and everything that happens inside of
that CFC doesn't affect anything outside - unless it is specifically
programmed via a function to do so and you call that function and ask it
to do its task.
You can read books about object oriented programming and they'll make
sense, but in my experience, you need to work with it for several months
at least until it begins to click. Before you begin to have enough
experience to understand it - from your own experience. OO is really a
unique challenge, in that it gives you a few principles to go by and
leaves you to implement them on your own, and each application will be
different. Becoming proficient here takes years of experience.
The CF language gives you a few basic constructs you can use to
implement OO in your applications, but it doesn't at all force you to.
Stephen Adams wrote:
Hi,
I am trying to run a query and I'm trying to get the application.DSN I
have set in my application.cfm file, I can't use <cfquery name="query"
datasource="#application.dsn#"> should I be using variables.DSN or is
better practice to create a init() function (as a constructor) and
pass the DSN details as part of the init() function. Which should be
accessible to the queries in my CFC. I could also check if I have a
connection to the database in this init function and throw an error if
no connection is found.
What do you guys think?
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject
of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
