The data in the database changes of course but that's not what you are
storing in the application scope... you are storing the component
Eg...
<cfif not isdefined('application.inventory')>
<cfset application.inventory = createObject("component",
"cfcs.inventory").init(request.dsn) />
(and any other components you need to store)
</cfif>
Then from now on..
<cfset myResults = application.inventory.myMethod(myArguments) />
<cfdump var="#myResults#" />
..:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.
Bobby Hartsfield
http://acoderslife.com
-----Original Message-----
From: Vince Collins [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 20, 2007 11:21 AM
To: CF-Talk
Subject: Re: Instantiating all objects within Application.cfm
The data within the database changes, not the schema per se, however I do
want to pass sorts and filters to these queries.
application vs request is unclear now to me. If I allow them to filter the
query or sort it, I thought it should be scoped to request. No?
Sorry if I sound inane here.
v
Brian Kotek wrote:
> On 9/20/07, Vince Collins <[EMAIL PROTECTED]> wrote:
>
>> Thanks Brian
>>
>> I failed to mention that these are my database cfcs which will often
>> change so application scope isn't the best choice for me.
>>
>
>
> When you say they will "often change", what do you mean? You're
> changing the SQL or column names?
>
> Even though
>
>> I'm not actually calling a database CRUD method yet, I wanted a
>> handle on the objects to grab later down in the page build. It's a
>> small application but every page request will be returning dynamic data.
>>
>
>
> I just want to be sure you're not doing this unnecessarily. You can
> store the CFC in the application scope and every call to it can return
> different database results. In fact, this is how almost every
> database-related CFC works.
>
> Is there a lot more overhead instantiating an object versus say
> <cfparam
>
>> name="blah" default=""> ?
>>
>
>
> Actually, because cfparam evaluates what you have in the default
> attribute regardless of whether the value exists or not, cfparam would
> probably perform much more badly. I think cfparam should really be
> avoided as much as possible for this reason.
>
> Brian Kotek wrote:
>
>>> Well, you're creating the CFCs over and over on every single
>>> request,
>>>
>> which
>>
>>> is probably not good. Depending on what the CFCs do, and whether
>>> they
>>>
>> are
>>
>>> stateless (have no changing instance data) or stateful (holds
>>> changing instance data, or holds different instance data for each
>>> user), most
>>>
>> people
>>
>>> store stateless instances in the application scope so they are only
>>>
>> created
>>
>>> once during the lifetime of the application. Stateful CFC are harder
>>> to store in the application scope since concurrency must be dealt
>>> with, and "per-request" CFCs (CFCs that are unique to each user or
>>> to each
>>>
>> request)
>>
>>> can't be easily kept in the application scope, and must be created
>>> for
>>>
>> each
>>
>>> request or possibly stored in the session scope.
>>>
>>>
>>>
>>>
>>>
>
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Download the latest ColdFusion 8 utilities including Report Builder,
plug-ins for Eclipse and Dreamweaver updates.
http;//www.adobe.com/cfusion/entitlement/index.cfm?e=labs%5adobecf8%5Fbeta
Archive:
http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:288964
Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
