Michael S Hodgdon
Web Development Project Manager
617 - 669 - 7183
[EMAIL PROTECTED]
----- Original Message -----
From: Raymond Camden
To: CF-Talk
Sent: Wednesday, February 25, 2004 10:14 AM
Subject: RE: problems accessing variables with components
Please see my comments in the code below.
> <!--- COLDFUSION COMPONENT: hcp.cfc ---> <cfcomponent
> displayname="hcp" extends="main" hint="I contain methods that
> load and access information for the entire hcp.com application.">
>
>
> <!--- METHOD: initializeObject() --->
> <cffunction name="initializeObject" access="public"
> output="no" hint="I prepare content, routines, and objects
> for hcp.com">
>
> <!--- Attempt to run the function code --->
> <cftry>
>
>
> <!--- Obtain the top-level market topics from the database --->
> <cfinvoke
> component="#server.database#"
> method="selectTopics"
> prefixFilter="m1"
> returnvariable="sthcpInfo.aMarkets">
First problem. Your method creates a variable called sthcpInfo.aMarkets. If
this variable is only meant to last for the execution of this method, you
should var scope it. Also, I'd called it bad practice to have cfinvoke
return a variable named x.y. Yes, CF will automatically create a structure
and member for you, but you should really just return the variable as
aMarkets or something else. Assuming you return it as aMarkets, you should
add
<cfset var aMarkets = "">
at the top of your cffunction call. Ditto for any other variable you create,
like current_market. Not var scoping your variables can defintely lead to
issues under load.
{Michae Hodgdon} - These values are indeed persistant. This information rarely changes, so rather than make constant database hits, we are keeping the aMarkets array in a structure called sthcpInfo. stHcpinfo also holds other persistant information that we would like to keep persistance. So essentially, this information is designed to be read only, and set in memory only on initialization of this object. Access is received through the getRoutines that we have set.
> <!--- For each market returned by the database... --->
> <cfloop from="1" to="#ArrayLen(sthcpInfo.aMarkets)#"
> step="1" index="current_market">
> <cflock scope="SERVER" type="EXCLUSIVE" timeout="30">
>
> <!--- Create a new topic object for this market in server
> memory--->
> <cfset
> "server.#sthcpInfo.aMarkets[current_market].topic#" =
> CreateObject("component", "cf_components.topic")>
Why do you do this? You are already storing the CFC itself in server memory
- why not store these values in the CFC itself - in the Variables scope.
Then the values will exist as long as the CFC itself exists.
{Michael Hodgdon} - Each market has many routines that it runs as well personal information about that market. So we are using the "topic" cfc as a blueprint, and then we create an object for each market using that blueprint. For easy access, we reference the aMarkets cfc to output all the markets we have (for instance, on the home page our markets are ....). When you are on a market page itself, we access that markets objects to return more detailed and rich information.
> <!--- run the initializeObject routine to init this object--->
> <cfset
> Evaluate("server.#sthcpInfo.aMarkets[current_market].topic#.in
> itializeObject(sthcpInfo.aMarkets[current_market].topic)")>
Not that it matters, but you don't need to use evaluate here. I'd change it
to
{Michael Hodgdon} - Good point, noted ;-)
<cfset
server[sthcpinfo.amarkets[current_market]].topic.initializeObject(....)>
Again though, I'd move this stuff out of the server scope anyway.
{Michael Hodgdon} - interestingly so, that is something we have been questioning ourselves. Our initial intent was to minimize server load by keeping persisant read only memory on hand in the server scope. For instance, aMarkets rarely changes. In fact most of whats in the hcp.cfc rarely changes. Therefore, rather than constantly load these objects into local memory, we drop them into the server scope and access them there. Are you saying that because these objects are stored in server memory and all of our web users access that same object in server memory we could be creating problems? We are really concerned about server load and performance. If we are loading these objects into local memory rather than server, should we not be concerned with this?
Thank you so much Ray
Thats all for now - I'd defintely add the var scoping.
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
