RE: Clarification Required Concerning CFC...
Sounds good, Jason.
Thanks for the overview and examples!
This is making more and more sense each hour!
Rick
> -Original Message-
> From: Jason Durham [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 23, 2008 11:55 AM
> To: CF-Talk
> Subject: RE: Clarification Required Concerning CFC...
>
> As others have mentioned... don't fight OO. :) It takes a bit of time
> to adjust but it will all come together and you'll be a more productive
> developer as a result.
>
> As someone mentioned, the variable scope is local to the page (doesn't
> matter if the file ends in cfc or cfm). You aren't *including* a
> component, you're creating a copy of it in memory. When you initialize
> each of the objects, sometimes they require variables to function (DSN
> is a good example). Take this as an example...
>
> Let's say you want to group all of your data access (queries) functions
> into one CFC. All of these functions merely get/insert/update based
> upon arguments sent to them. While they may return different results,
> they are essentially 'reset' after they are executed. Since you're
> going to have several methods that all depend on the same DSN, you can
> inject the DSN into the init() function and store the variable in a
> scope that is available to all methods on that 'page'. Since this CFC
> merely returns queries, you could store this CFC in a scope that allows
> it to persist across many page requests. For the purpose of learning,
> think about it this way...
>
>
> From Application.cfc...
>
> output="false">
>
>
>
>
>
>
>
> createObject("component","path.to.UserGateway").init(myDsn,myUser,myPwd)
> />
> createObject("component","path.to.UserGateway").init(myDsn,myUser,myPwd)
> />
> createObject("component","path.to.NewsletterGateway").init(myDsn,myUser,
> myPwd) />
>
>... include any other application stuff you want ...
>
>
>
> When you're application loads, you create variables to hold your DB
> credentials and DSN. Then you inject variables into each of your CFCs
> that communicate with that DB. Now let's look inside one of those
> Gateway objects.
>
> From UserGateway.cfc...
>
>
> returntype="UserGateway">
>
> hint="ColdFusion datasource's username." />
> hint="ColdFusion datasource's password." />
>
>
>
>
>
>
>
>
>
> returntype="query">
> default="false" hint="Limit results to users marked active in
> database."/>
>
>
>
>
>
> username="variables.dbUsr" password="variables.dbPwd">
> SELECT *
> FROM tbl_User
> WHERE 0=0 AND is_Active = 1
>
>
>
>
>
> There are a couple of OO practices going on here. In Application.cfc,
> you have injected the DB config/credentials into the init() method. The
> init() method simply passes those arguments into the variables scope
> when the object is created. All of the methods from within that
> component have access to the variables scope. Therefore... all of them
> have access to the DB config/credentials. So now you've got a
> Application.oUserGateway object hanging around in memory for you to use
> to perform CRUD operations on Users. When it's time for you to get a
> list of users, you can simply invoke the method on any template in the
> application by doing this...
>
> From within XYC.cfm
>
>
>
>
> The equivalent is this...
> returnvariable="qActiveUsers" isActive="true" />
>
> You see how much extra typing is involved with , which is why
> I prefer the cfset way to do it. Anyway, that invocation is accessing
> the UserGateway from memory, running getUsers with an argument value of
> 'true'. That may seem like quite a bit of typing just to get a user
> list huh? The beauty is, you can reuse that UserGateway object on
> another app because it knows *nothing* about *anything* that hasn't been
> explicitly provided. If your DB password changes, you make ONE change
> (onApplicationStart) and reload the app. That is a basic form of
> encapsulation. If application requires new user fields in the database,
> or is_active changes from Boolean to another datatype, it's much easier
> to search/replace/modify all of your queries in one place.
>
> Setting up the OO model takes some time. What works best for you might
> not work best for us. T
RE: Clarification Required Concerning CFC...
As others have mentioned... don't fight OO. :) It takes a bit of time to adjust but it will all come together and you'll be a more productive developer as a result. As someone mentioned, the variable scope is local to the page (doesn't matter if the file ends in cfc or cfm). You aren't *including* a component, you're creating a copy of it in memory. When you initialize each of the objects, sometimes they require variables to function (DSN is a good example). Take this as an example... Let's say you want to group all of your data access (queries) functions into one CFC. All of these functions merely get/insert/update based upon arguments sent to them. While they may return different results, they are essentially 'reset' after they are executed. Since you're going to have several methods that all depend on the same DSN, you can inject the DSN into the init() function and store the variable in a scope that is available to all methods on that 'page'. Since this CFC merely returns queries, you could store this CFC in a scope that allows it to persist across many page requests. For the purpose of learning, think about it this way... >From Application.cfc... ... include any other application stuff you want ... When you're application loads, you create variables to hold your DB credentials and DSN. Then you inject variables into each of your CFCs that communicate with that DB. Now let's look inside one of those Gateway objects. >From UserGateway.cfc... SELECT * FROM tbl_User WHERE 0=0 AND is_Active = 1 There are a couple of OO practices going on here. In Application.cfc, you have injected the DB config/credentials into the init() method. The init() method simply passes those arguments into the variables scope when the object is created. All of the methods from within that component have access to the variables scope. Therefore... all of them have access to the DB config/credentials. So now you've got a Application.oUserGateway object hanging around in memory for you to use to perform CRUD operations on Users. When it's time for you to get a list of users, you can simply invoke the method on any template in the application by doing this... >From within XYC.cfm The equivalent is this... You see how much extra typing is involved with , which is why I prefer the cfset way to do it. Anyway, that invocation is accessing the UserGateway from memory, running getUsers with an argument value of 'true'. That may seem like quite a bit of typing just to get a user list huh? The beauty is, you can reuse that UserGateway object on another app because it knows *nothing* about *anything* that hasn't been explicitly provided. If your DB password changes, you make ONE change (onApplicationStart) and reload the app. That is a basic form of encapsulation. If application requires new user fields in the database, or is_active changes from Boolean to another datatype, it's much easier to search/replace/modify all of your queries in one place. Setting up the OO model takes some time. What works best for you might not work best for us. This topic seems pretty popular and it doesn't seem to be too hard to get opinions on it. Keep trying to work through it brotha. :) Keep in mind, this example is just for general CRUD components. You don't want to load every object into the Application scope (especially on a shared server). Try to stay away from using CGI, session, request, application, or server scopes from within your components. Instead, pass those values into a method via an argument. -Original Message----- From: Rick Faircloth [mailto:[EMAIL PROTECTED] Sent: Saturday, June 21, 2008 10:11 PM To: CF-Talk Subject: RE: Clarification Required Concerning CFC... > That would make less sense. The Variables scope is the local scope for any > CF program. CFM and CFC files are both CF programs. It just seems to make little sense to have two scopes named the same thing which have nothing to do with each other. It would be like me creating two variables with the same name, but having different values. Now that would be confusing! I could have variables.time in a cfc that is 4pm, but variables.time outside a cfc which has the value of 4am, right? If so, a scope exclusive to cfc's would seem to make more sense. cfcVariables.time vs variables.time... instantly recognizable. That's just the way it seems as I get started with cfc's... Rick ~| Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to date Get the Free Trial http://ad.doubleclick.net/clk;203748912;27390454;j Archive: http://www.houseoffus
RE: Clarification Required Concerning CFC...
Dave, Ah... But a lot of folks come to CFCs from using cfincludes. Modular code from many legacy CF applications really means stringing together procedural code by including various files. In fact, a lot of display code is still written like this (and why not). So from that standpoint these folks have the same wonderment as folks who were moving to custom tags in cf 5 - except cfcs are more complicated. -mark Mark A. Kruger, CFG, MCSE (402) 408-3733 ext 105 www.cfwebtools.com www.coldfusionmuse.com www.necfug.com -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Saturday, June 21, 2008 10:27 PM To: CF-Talk Subject: RE: Clarification Required Concerning CFC... > It just seems to make little sense to have two scopes named the same > thing which have nothing to do with each other. This is true for any two separate CF programs. Each CF program has its own local scope. The same is true for CFML custom tags. > I could have variables.time in a cfc that is 4pm, but variables.time > outside a cfc which has the value of 4am, right? Yes, because the CFC is a separate program. I could have variables.time in a CFM file, and variables.time outside that file, and those would be two separate variables. Again, this is the same for CFML custom tags. Each file has its own local variables scope. It's been like that since CF3. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ~| Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to date Get the Free Trial http://ad.doubleclick.net/clk;203748912;27390454;j Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:307937 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Clarification Required Concerning CFC...
What! Adobe must submit or I'll... I'll... oh, forget it. > -Original Message- > From: Will Tomlinson [mailto:[EMAIL PROTECTED] > Sent: Sunday, June 22, 2008 12:32 AM > To: CF-Talk > Subject: Re: Clarification Required Concerning CFC... > > >It just seems to make little sense to have two scopes named the same thing > >which have nothing to do with each other. It would be like me creating > >two variables with the same name, but having different values. Now that > >would > >be confusing! > > Would you just go with the flow? I doubt Adobe is gonna change it to your > liking anytime soon. > > :) > > Will > > ~| Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to date Get the Free Trial http://ad.doubleclick.net/clk;203748912;27390454;j Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:307929 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: Clarification Required Concerning CFC...
I see what you're saying. I guess I just haven't had to use the various scopes in a way that brought the variables scope that much in focus... > -Original Message- > From: Dave Watts [mailto:[EMAIL PROTECTED] > Sent: Saturday, June 21, 2008 11:27 PM > To: CF-Talk > Subject: RE: Clarification Required Concerning CFC... > > > It just seems to make little sense to have two scopes named > > the same thing which have nothing to do with each other. > > This is true for any two separate CF programs. Each CF program has its own > local scope. The same is true for CFML custom tags. > > > I could have variables.time in a cfc that is 4pm, but > > variables.time outside a cfc which has the value of 4am, right? > > Yes, because the CFC is a separate program. I could have variables.time in a > CFM file, and variables.time outside that file, and those would be two > separate variables. Again, this is the same for CFML custom tags. Each file > has its own local variables scope. It's been like that since CF3. ~| Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to date Get the Free Trial http://ad.doubleclick.net/clk;203748912;27390454;j Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:307928 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Clarification Required Concerning CFC...
>It just seems to make little sense to have two scopes named the same thing >which have nothing to do with each other. It would be like me creating >two variables with the same name, but having different values. Now that would >be confusing! Would you just go with the flow? I doubt Adobe is gonna change it to your liking anytime soon. :) Will ~| Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to date Get the Free Trial http://ad.doubleclick.net/clk;203748912;27390454;j Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:307927 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Clarification Required Concerning CFC...
> It just seems to make little sense to have two scopes named > the same thing which have nothing to do with each other. This is true for any two separate CF programs. Each CF program has its own local scope. The same is true for CFML custom tags. > I could have variables.time in a cfc that is 4pm, but > variables.time outside a cfc which has the value of 4am, right? Yes, because the CFC is a separate program. I could have variables.time in a CFM file, and variables.time outside that file, and those would be two separate variables. Again, this is the same for CFML custom tags. Each file has its own local variables scope. It's been like that since CF3. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ~| Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to date Get the Free Trial http://ad.doubleclick.net/clk;203748912;27390454;j Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:307924 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Clarification Required Concerning CFC...
The variables scope in page1.cfm and the variables scope in page2.cfm are called the same thing and are not related. The variables scope in cfc1.cfc is also not related. It's perfectly consistent. On Sun, Jun 22, 2008 at 11:10 AM, Rick Faircloth <[EMAIL PROTECTED]> wrote: >> That would make less sense. The Variables scope is the local scope for any >> CF program. CFM and CFC files are both CF programs. > > It just seems to make little sense to have two scopes named the same thing > which have nothing to do with each other. It would be like me creating > two variables with the same name, but having different values. Now that would > be confusing! > > I could have variables.time in a cfc that is 4pm, but variables.time outside > a cfc which has the value of 4am, right? > > If so, a scope exclusive to cfc's would seem to make more sense. > cfcVariables.time vs variables.time... instantly recognizable. > > That's just the way it seems as I get started with cfc's... > > Rick > >> -Original Message- >> From: Dave Watts [mailto:[EMAIL PROTECTED] >> Sent: Saturday, June 21, 2008 10:13 PM >> To: CF-Talk >> Subject: RE: Clarification Required Concerning CFC... >> >> > However, I *do* wish they had come up with a different name >> > for the scope exclusive to CFC's! Maybe something >> > "varcomponent" or something. Anything besides the name of a >> > scope already in use elsewhere! >> >> That would make less sense. The Variables scope is the local scope for any >> CF program. CFM and CFC files are both CF programs. >> >> Dave Watts, CTO, Fig Leaf Software >> http://www.figleaf.com/ >> > > > > ~| Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to date Get the Free Trial http://ad.doubleclick.net/clk;203748912;27390454;j Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:307923 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: Clarification Required Concerning CFC...
> That would make less sense. The Variables scope is the local scope for any > CF program. CFM and CFC files are both CF programs. It just seems to make little sense to have two scopes named the same thing which have nothing to do with each other. It would be like me creating two variables with the same name, but having different values. Now that would be confusing! I could have variables.time in a cfc that is 4pm, but variables.time outside a cfc which has the value of 4am, right? If so, a scope exclusive to cfc's would seem to make more sense. cfcVariables.time vs variables.time... instantly recognizable. That's just the way it seems as I get started with cfc's... Rick > -Original Message- > From: Dave Watts [mailto:[EMAIL PROTECTED] > Sent: Saturday, June 21, 2008 10:13 PM > To: CF-Talk > Subject: RE: Clarification Required Concerning CFC... > > > However, I *do* wish they had come up with a different name > > for the scope exclusive to CFC's! Maybe something > > "varcomponent" or something. Anything besides the name of a > > scope already in use elsewhere! > > That would make less sense. The Variables scope is the local scope for any > CF program. CFM and CFC files are both CF programs. > > Dave Watts, CTO, Fig Leaf Software > http://www.figleaf.com/ > ~| Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to date Get the Free Trial http://ad.doubleclick.net/clk;203748912;27390454;j Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:307922 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Clarification Required Concerning CFC...
> However, I *do* wish they had come up with a different name > for the scope exclusive to CFC's! Maybe something > "varcomponent" or something. Anything besides the name of a > scope already in use elsewhere! That would make less sense. The Variables scope is the local scope for any CF program. CFM and CFC files are both CF programs. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ~| Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to date Get the Free Trial http://ad.doubleclick.net/clk;203748912;27390454;j Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:307920 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Clarification Required Concerning CFC...
Thanks, Josh. That makes perfect sense now. However, I *do* wish they had come up with a different name for the scope exclusive to CFC's! Maybe something "varcomponent" or something. Anything besides the name of a scope already in use elsewhere! Thanks for straightening me out. Rick > -Original Message- > From: Josh Nathanson [mailto:[EMAIL PROTECTED] > Sent: Saturday, June 21, 2008 1:14 PM > To: CF-Talk > Subject: Re: Clarification Required Concerning CFC... > > Rick - in the CFC function, variables.DSN refers to the variables scope > within the CFC only. So, you are setting the variables.DSN value, in the > instance of the object you're creating, to the value that is passed in as an > argument, arguments.DSN. > > The variables scope within a CFC is local to that CFC, and cannot be > accessed from outside it. Thus, any use of the variables scope from your > calling page, will be entirely separate from any use of the variables scope > within the CFC. This is why you have to pass in values to your CFC via > arguments, so that the CFC variable values (the "object instance" values > more specifically) can be set in the init function of the CFC. > > This is quite different than the use of cfinclude -- it's a whole different > way of thinking about things so it takes a while to wrap your mind around > it. > > -- Josh > ~| Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to date Get the Free Trial http://ad.doubleclick.net/clk;203748912;27390454;j Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:307914 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Re: Clarification Required Concerning CFC...
Rick - in the CFC function, variables.DSN refers to the variables scope within the CFC only. So, you are setting the variables.DSN value, in the instance of the object you're creating, to the value that is passed in as an argument, arguments.DSN. The variables scope within a CFC is local to that CFC, and cannot be accessed from outside it. Thus, any use of the variables scope from your calling page, will be entirely separate from any use of the variables scope within the CFC. This is why you have to pass in values to your CFC via arguments, so that the CFC variable values (the "object instance" values more specifically) can be set in the init function of the CFC. This is quite different than the use of cfinclude -- it's a whole different way of thinking about things so it takes a while to wrap your mind around it. -- Josh - Original Message - From: "Rick Faircloth" <[EMAIL PROTECTED]> To: "CF-Talk" Sent: Saturday, June 21, 2008 9:44 AM Subject: Clarification Required Concerning CFC... > Hi, all... > > This statement in a CFC function confuses me: > > > > Why? Because it seems backwards. It seems to me that > I've already defined my variables.DSN values outside of > the CFC and am passing that value into CFC as an argument. > > It only makes sense, then, for me to use this, instead: > > > > Backwards from the way it was written above. It seems I should > be setting arguments.DSN equal to variables.DSN. > > According to this example written from the calling page: > > > > > I'm creating an object and specifying the DSN value as "variables.DSN", > and it only makes sense that in the called CFC function, that the function > would then create a value for arguments.DSN equal to variables.DSN or, > . > > Can someone explain why it's not backwards to write > in the function? > > Thanks, > > Rick > > > ~| Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to date Get the Free Trial http://ad.doubleclick.net/clk;203748912;27390454;j Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:307913 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
