I think to solve the actual problem about accessing certain information 
across different applications, server scope is a good solution. Matt 
doesn't need to store the whole app scope in server scope, just access the 
number of users currently accessing the application or many applications.

Copying the application scope every single time you want to know how many 
users are using an application, would be inefficient.

Darryl 

[EMAIL PROTECTED] wrote on 31/03/2005 01:45:53 PM:

> Q. If you were to store the application scope by reference into the
> server-scope, won't that be a painful way?
> 
> Instead why not simply have a Application Name registry, where all it
> does is store names, then using steves method simply copy from one to
> the other via this named scope.
> 
> In order to copy, you're gonna have to provide a source and target,
> thats a given and not knowing your source is will "eh?" - even then
> you could loop the name registry and pull that  in dynamically (if
> your hard pressed to couple your applications with names and what
> not).
> 
> Catch22 is if you clear your application scope, using StructClear etc
> you will also wipe the Application Name - from memory i think that
> once you do that, your application name is gone until your actual
> application.cfm times out... (ie refresh won't bring it back..its
> gawwwwwwn.....)
> 
> To me storing your entire application scope or anything but bar
> miniums inside server-scope seems like a big ol waste.
> 
> I like (think this was what Andrew was hinting at) the idea of
> CFAdministrator having an Application Scope Profilier so you can view
> an application scope remotely or stuff like that...some sort of
> recursion ui/ide/profiler thingy.
> 
> On Thu, 31 Mar 2005 12:29:43 +1000, Andrew Scott <[EMAIL PROTECTED]> wrote:
> > Steve,
> > 
> > The point is very clear that you need to know the application nameto 
change
> > it too, and if you don't know then your in trouble!! Either way, its 
another
> > solution to using the application name. Because if your like me and I 
am
> > looking at doing this, is that if you have many websites and you want 
to
> > kill a specific session, your able to by getting a list of the 
applications
> > that are running, then delve a little further into and kill the 
variable or
> > even add to the variables.
> > 
> > The reason I say this is that in a control panel situation I can add a
> > variable to the application structure, which can be checked by the
> > application to see if it exists and holds a particular value, and 
place a
> > hold on that website so that I can do maintenance to the website then 
when I
> > am finished I can click another button on the control panel and its 
back
> > online again.
> > 
> > This is not a shot at you Steve, but I suggested that because others 
might
> > not know about it and in this case it wasn't very clear as the reason 
behind
> > what it is he wanted to do.
> > 
> > 
> > Regards
> > Andrew Scott
> > Technical Consultant
> > 
> > NuSphere Pty Ltd
> > Level 2/33 Bank Street
> > South Melbourne, Victoria, 3205
> > 
> > Phone: 03 9686 0485  -  Fax: 03 9699 7976
> > 
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Steve 
Onnis
> > Sent: Thursday, 31 March 2005 11:51 AM
> > To: CFAussie Mailing List
> > Subject: [cfaussie] RE: Accessing application vars from a diff 
Application.
> > 
> > grrrrrrrrr
> > 
> > Just change the name of the application in the application tag
> > 
> > <cffunction name="copyApplication">
> > 
> >         <cfargument name="sourceApplication" type="string" 
required="Yes" />
> >         <cfargument name="destinationApplication" type="string"
> > required="Yes" />
> > 
> >         <cfapplication name="#arguments.sourceApplication#" />
> >         <cfset source = duplicate(Application)>
> > 
> >         <cfapplication name="#arguments.destinationApplication#" />
> >         <cfset structAppend(application, source)>
> > 
> > </cffuntion>
> > 
> > <cfset
> > 
copyApplication(sourceApplication="blip",destinationApplication="blop")>
> > 
> > ---
> > You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
> > To unsubscribe send a blank email to [EMAIL PROTECTED]
> daemon.com.au
> > Aussie Macromedia Developers: http://lists.daemon.com.au/
> > 
> 
> 
> -- 
> Regards,
> Scott Barnes
> http://www.mossyblog.com
> http://www.flexcoder.com (Coming Soon)
> 
> ---
> You are currently subscribed to cfaussie as: 
[EMAIL PROTECTED]
> To unsubscribe send a blank email to 
[EMAIL PROTECTED]
> Aussie Macromedia Developers: http://lists.daemon.com.au/



To unsubscribe from this email please forward this email to [EMAIL PROTECTED] 

This email message is confidential and may be privileged. Unauthorised use, 
copying or distribution of any part of this email
including attachments is prohibited.  If you are not the intended recipient 
please forward the email to [EMAIL PROTECTED]
and delete the original. 

ABN AMRO Morgans Limited and its associates hold or may hold securities in the 
companies/trusts mentioned herein.  Any general
advice included in this email has been prepared without taking into account 
your objectives, financial situation or needs.  Before
acting on the advice, you should consider its appropriateness or discuss with 
one of our investment advisors.

To the extent permitted by law we exclude (and where the law does not permit an 
exclusion, limit to the extent permitted by law) all
liability for any direct, indirect and consequential costs, losses, damages and 
expenses incurred in any way (including but not limited
to that arising from negligence), connected with any use or access to this 
email or any reliance on information contained in this email
or any attachments.

ABN AMRO Morgans Limited (ABN 49 010 669 726 AFSL 235410) A Participant of ASX 
Group  A Principal Member of the
Financial Planning Association


---
You are currently subscribed to cfaussie as: [email protected]
To unsubscribe send a blank email to [EMAIL PROTECTED]
Aussie Macromedia Developers: http://lists.daemon.com.au/

Reply via email to