Newbie Q: Where to put DSN setting?

[RobG]

Yeah sounds pretty stupid, I know. :)

Fortunately I subbed to this list at its inception and have saved all
the posts, so I've been going through them and learning a lot. But
here's one that I haven't figured out.

Simply put, how/where do you specify your DSN? The issue I'm having is
I'm building a site that is going to be almost entirely AJAX-based (via
jQuery). For the sake of simplicity, I'm building a Contact form. User
fills out form, clicks submit. I will display the classic "Processing"
animated graphic, while we call a method inside the contact.cfc service
to email the form's contents and also dump them to a db table.

But the issue I'm having is how to get the DSN into the CFC without
resorting to calling it request.dsn. In the past, I've always passed it
in via the init() method, but since this is a service that is being
instantiated by the framework, I'm not sure how to accomplish that.

What's the best way to do this?

Thanks!

Rob

[Eapen]

You can set it with 

variables.dsn = "mydsn"

in the Application.cfc or in your controller.cfc (although that might be frowned upon).

--
You received this message because you are subscribed to the Google Groups "framework-one" group.
To post to this group, send email to framew...@googlegroups.com.
To unsubscribe from this group, send email to framework-on...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/framework-one?hl=en.

[RobG]

On 3/31/10 1:31 PM, Eapen wrote:
> You can set it with
> variables.dsn = "mydsn"
> in the Application.cfc or in your controller.cfc (although that might be
> frowned upon).

So if I set it in App.cfc, it will find its way into the service?

I had tried adding a key to variables.frameworks
(variables.frameworks.dsn) and that wasn't visible in the service.

Rob

[Jamie Krug]

To have your DSN (or anything, really) injected into a service, use a bean factory like ColdSpring. If you have something really simple, with few dependencies, you could even roll your own simple CFC as long as you honor the hasBean() and getBean() API required by FW/1.

[Eapen]

No, it wont make its way into the service. I had to hard-code the variables.dsn into the service cfc. Since I don't use bean factories - this was the easiest solution I found.

Rob

[Fernandez, Miguel]

I am a newbie as well and just wanted to point out this statement from the documentation about services:

 

Services should not know anything about the framework. When a service CFC is created by FW/1, it's init() method is invoked (if present) and no arguments are passed in, unlike a controller's init() method. Service methods should not "reach out" into the request scope to interact with FW/1, they should simply have some declared arguments, perform some operation and return some data.

 

Found here: http://fw1.riaforge.org/wiki/index.cfm/DevelopingApplicationsManual#Designing_Services

 

I think the framework is designed for the controller to handle passing the necessary vars to the service.

- Miguel

---

---

Attention:
Kentucky Farm Bureau has updated their "Primary" e-mail addresses. My new "Primary" e-mail address is Miguel.F...@kyfb.com. Please make a note of the new e-mail address. My old email address will also be valid as a secondary address going forward.

[Kevan Stannard]

If you are not using a bean factory, then there are couple of ways I might do this.

First, in the FW/1 setupApplication() function I'd put your settings into the application scope

function setupApplication() {

    var settings = {};

    settings.dsn = "mydsn";

    // Other settings here

    application.settings = settings;

}

Next, if you're comfortable with inheritance I'd create a BaseService.cfc that your other Services extend. This BaseService would have one function

getSettings() {

    return application.settings;

} 

Alternatively, you could create an include file serviceFunctions.cfm and cfinclude this at the top of each of service.cfc. This would contain the same function as above:

getSettings() {

    return application.settings;

} 

Then in your service code, just call getSettings() to get access to all your dsn:

<cfquery datasource="#getSettings().dsn#" ... >

[Jamie Krug]

I'd say the framework is designed to implicitly call service methods,
in a conventions based manner. That convention allows for relevant
request context arguments to make their way to service method calls.
Controllers can also invoke service methods, but should not hold the
responsibility of passing in intitialization args or other
dependencies.

I'd suggest considering ColdSpring for this purpose. Worst case, I'd
reference the application scope for app context properties in
services, rather than unnecessarily coupling contollers with service
dependencies.

> <mailto:framework-one%2Bunsu...@googlegroups.com> .

> For more options, visit this group at
> http://groups.google.com/group/framework-one?hl=en.
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "framework-one" group.
> To post to this group, send email to framew...@googlegroups.com.
> To unsubscribe from this group, send email to
> framework-on...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/framework-one?hl=en.
>
>
>

> Attention:
> Kentucky Farm Bureau has updated their "Primary" e-mail addresses. My new
> "Primary" e-mail address is Miguel.F...@kyfb.com. Please make a note of
> the new e-mail address. My old email address will also be valid as a
> secondary address going forward.
>

[RobG]

On 3/31/10 2:44 PM, Kevan Stannard wrote:
> If you are not using a bean factory, then there are couple of ways I
> might do this.
>
> First, in the FW/1 setupApplication() function I'd put your settings
> into the application scope
>
> function setupApplication() {
> var settings = {};
> settings.dsn = "mydsn";
> // Other settings here
> application.settings = settings;
> }

I'm going this route and using a base.cfc. So next stupid question...
is setupApplication an already-existing function, or do I put it into my
App.cfc?

I may end up using ColdSpring, but for now, this seems like a good way
to go.

Rob

[Kevan Stannard]

You need to add setupApplication() to your Application.cfc and FW/1
will automatically call it.

[wally....@comcast.net]

All of these solutions are complicated ways to pretend that the services or any cfc know nothing about the environment in which they run.  That is bad logic.  Forget all these esoteric non-sense.   Set an application variable and use is in all cfqueries in all cfcs.   application.mydsn="mydatasource"; 

Use application.mydsn in all queries.

End of problem.  Simple, accessible from any place in the code base at any time.  We get so wrapped up in the mantra of object oriented purity that we forget the option to use simple solutions.   The important thing is to be consistent.    Coldfusion is NOT JAVA.  It is NOT C#.  It is an elegant tag based language that can greatly simplify development tasks.  Don't make something complicated out of something simple!  

 

Too many of the discussions on this site are dealing with the  politically "correct" OO philosophy.    When business logic becomes lost in convoluted OO structures requiring major analysis to understand each time you pick up the code something is wrong!  Keep it simple.

 

 

----- Original Message -----
From: "Kevan Stannard" <kevans...@gmail.com>
To: framew...@googlegroups.com
Sent: Wednesday, March 31, 2010 5:44:51 PM GMT -05:00 US/Canada Eastern
Subject: Re: [framework-one] Newbie Q: Where to put DSN setting?

[Sean Corfield]

On Thu, Apr 1, 2010 at 5:50 AM, <wally....@comcast.net> wrote:
> All of these solutions are complicated ways to pretend that the services or
> any cfc know nothing about the environment in which they run.  That is bad
> logic.  Forget all these esoteric non-sense.   Set an application variable
> and use is in all cfqueries in all cfcs.
> application.mydsn="mydatasource";
>
> Use application.mydsn in all queries.

Wally is right in some ways. All the messing around we do with global
configuration and OO tends to come from the Java way of thinking -
because Java has no global variables and it's actually really hard to
implement the Singleton design pattern "correctly" in Java.

In my Design Patterns for ColdFusion presentation, I point out that
Application.cfc and the application scope give us a simple, out of the
box way to handle Singletons: create them in onApplicationStart()
(i.e., setupApplication() in FW/1) and use application scope to make
them globally available.

If that works for you, it's OK to do it that way. Really.

That said, the reason we make this fuss is really for testability and
reusability. If you have a CFC that depends on variables in shared
scopes, it is harder to test and harder to reuse - and it is also less
robust since its behavior can be modified inadvertently by other code
changing the environment.

That's why we talk so much about Dependency Injection / Inversion of
Control / Bean Factories. That allows us to move global configuration
to a single location that is then automatically injected into the
service CFCs. The CFCs then depend on the environment they were
created with rather than the current, dynamic state of the global
application environment. That makes testing easier, it makes reuse
easier, and it makes the components more robust.

Think of it as Phase 2 (or 3 or 4 or...). Consider moving to that
structure when you feel ready for it. OO doesn't have to be all or
nothing - treat it like eating an elephant and take on the parts that
work for you and don't worry about the parts that don't... until they
make sense or you find you need them!
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

[Reinhard Jung]

You can use FrameFactory One as well: ff1.riaforge.org

(sent from my phone, so please be forgiving of any spelling errors :)

[Charles Robertson]

I just created a configBean and added 'dsn' property to it. Using the 'application' scope inside a service or controller breaks encapsulation.

However I would rather that the configBean was a singleton rather than its default transient state. Is there any way to create a singleton bean?