Re: Flash Remoting bug, feature.... in variable persistence
On Thursday, Nov 21, 2002, at 07:20 US/Pacific, [EMAIL PROTECTED] wrote: Personally, I do not see much use for Remoting as a webservice, at least beyond fundamental operations. By building a fascade a CFC is forced to return control to the application developer, in my case, revealing far more information and control than I would like, and further increasing development time for both ColdFusion and Flash. I've been puzzling over this assertion and I still don't really understand it. By building a facade for Flash Remoting, you *hide* information and you *retain* control - you provide a very specific interface to Flash and how you manage state information is entirely transparent (you can use session scope, a database, whatever). The intent was a black box: the user requests, the CFC figures out how to handle it and returns, not vice-versa. And that's exactly how it works. A request is made, the CFC (facade) figures out how to handle it and returns. You are then free to design your server-side code however you like and modular design will probably lead you to create several stateless 'service' CFCs, some stateful 'object' CFCs - and your facade - which can lead to much more reuse. The problem is, in my case, that an outside developer could potentially unnecessarily burdening the server with requests to rebuild a query because an overly agressive application and would ruin overall performance for everyone. So I think your main concern is that you don't want to expose everything as a Web Service? And of course, you don't need to - the facade is the only Web Service and it can use authentication to ensure that no outside developer could call it. The CFC that deals with the query is then kept outside the wwwroot and called as needed from the secure Web Service. That doesn't even go to the fact that code that could be handled in one place is now pushed out to every application built around it... so much for reuse. Pushed out how? A facade *encapsulates* rather than exposes - it encourages reuse. In short, for Flash Remoting to be more than a 'toy', there needs to be a mechanism that keeps the object resident at least for the term of execution. There is - shared scopes on the server. Sean A Corfield -- Director, Architecture Web Technology Group -- Macromedia, Inc. tel: (415) 252-2287 -- cell: (415) 717-8473 aim: seancorfield -- http://www.macromedia.com An Architect's View -- http://www.corfield.org/blog/ Introducing Macromedia Contribute. Web publishing for everyone. Learn more at http://www.macromedia.com/contribute ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting.
Re: Re: Flash Remoting bug, feature.... in variable persistence
Sean - I knew you were going to say that, however, I can not help but feel that that execution model is inherently evil, and does nothing to help code reuse. Personally, I do not see much use for Remoting as a webservice, at least beyond fundamental operations. By building a fascade a CFC is forced to return control to the application developer, in my case, revealing far more information and control than I would like, and further increasing development time for both ColdFusion and Flash. The intent was a black box: the user requests, the CFC figures out how to handle it and returns, not vice-versa. The problem is, in my case, that an outside developer could potentially unnecessarily burdening the server with requests to rebuild a query because an overly agressive application and would ruin overall performance for everyone. Hence, it's something that I need the CFC should control. That doesn't even go to the fact that code that could be handled in one place is now pushed out to every application built around it... so much for reuse. In short, for Flash Remoting to be more than a 'toy', there needs to be a mechanism that keeps the object resident at least for the term of execution. Mike ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
Re: Flash Remoting bug, feature.... in variable persistence
Let me clarify a sentence:
To me this indicates the Flash takes the time to reload the CFC everytime. Basically
doing powerful than doing the following:
was meant to be:
To me, this indicates that Flash takes the time to reload the CFC everytime.
Basically doing nothing more powerful than the following:
**
Ok folks, the use of CFC's in Flash and ColdFusion is driving me bonkers.
The following is a scaled down version of a more complicated problem that brought
this to my attention. This is my very simple CFC. It stores a variable, and has one
function to return it and another to set it; I'll call it simple:
cfcomponent hint=very simple cfc
cfscriptstoreThisVariable = 2;/cfscript
cffunction name=getVar access=remote returntype=numeric
cfreturn storeThisVariable
/cffunction
cffunction name=setVar access=remote returntype=numeric
cfargument name=value type=numeric
cfset storeThisVariable = arguments.value
cfreturn storeThisVariable
/cffunction
/cfcomponent
Now, in ColdFusion, I can run the following code and it returns the expected results:
cfscript
simple = createObject(component,component/simple);
writeoutput(getvar: simple.getVar() br);
writeoutput(setvar: simple.setVar(3) br);
writeoutput(getvar: simple.getVar() br);
/cfscript
I get the following output, as I expect it would:
getvar: 2
setvar: 3
getvar: 3
In Flash, I run the following action script:
#include NetServices.as
#include DataGlue.as
isGatewayOpen = true;
NetServices.setDefaultGatewayUrl(http://myserver:8000/flashservices/gateway/;);
var gatewayConnnection = NetServices.createGatewayConnection();
var simple = gatewayConnnection.getService(CFAmp4.component.simple, this);
simple.getvar();
simple.setVar(3);
simple.getVar();
function getVar_result(result){
trace(getvar: + result);
}
function setVar_result(result){
trace(setvar: + result);
}
Unlike ColdFusion, this returns the following:
getvar: 2
setvar: 3
getvar: 2
To me this indicates the Flash takes the time to reload the CFC everytime Basically
doing powerful than doing the following:
http://localhost/simple.cfc?method=getvar
http://localhost/simple.cfc?method=setvarvalue=3
http://localhost/simple.cfc?method=getvar
This cannot possibly be the expected behavior.
I, of course, could code around this, but why?
Thanks
Mike Wokasch
~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription:
http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Signup for the Fusion Authority news alert and keep up with the latest news in
ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
Re: Flash Remoting bug, feature.... in variable persistence
On Wednesday, Nov 20, 2002, at 16:17 US/Pacific, [EMAIL PROTECTED] wrote: Ok folks, the use of CFC's in Flash and ColdFusion is driving me bonkers. Flash invokes CFCs in a manner that is very similar to Web Service consumption. Each invocation is 'new'. This cannot possibly be the expected behavior. Yup, it is by design. Note that Flash Remoting preserves your session so that session scope exists and is consistent across repeated calls. What you need to do is create a facade that Flash calls methods on and have the facade manage the 'persistence' of your CFC instance. What we typically do (and I wrote this up in an article on DesDev - about Design Patterns for Flash Remoting) is to build all our components to work independently of their environment - as you did with your simple CFC - and then build specific facade CFCs that are used by Flash Remoting. Those facades create the necessary instances of the 'worker' components and store them in session scope. The facade CFCs themselves are stateless in that they have no public or private instance data and they are the *only* CFCs which 'know about' the environment, i.e., session scope. Hope that helps clarify? Sean A Corfield -- Director, Architecture Web Technology Group -- Macromedia, Inc. tel: (415) 252-2287 -- cell: (415) 717-8473 aim: seancorfield -- http://www.macromedia.com An Architect's View -- http://www.corfield.org/blog/ Introducing Macromedia Contribute. Web publishing for everyone. Learn more at http://www.macromedia.com/contribute ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm
