For myself, and because ActionScript is such a powerful language, I do
most of the heavy lifting client side and save the server for services
that do things like persistance, heavy xml parsing, file tasks. When you
really start building rich apps you'll find the server implementation
becomes extreemly lightweight.. and the client can get very complex very
fast. It is generally agreed in the best way to do this is to create a
service delegate in flash that abstracts a webserice/cfc/xml
doc/csv/whatever you please.
For example, say you have a CheckOut.cfc-- I'd create a
CheckOutDelegate.as that provides an actionscript interface to client
ActionScript code, hiding the implementation of the server scripting
language. You don't want your delegates to talk directly to any UI
objects. I like to use what I'm calling control dispatchers. A control
dispatcher exists for each magor UI element. Its job is to control the
flow of events between UI components and service delegates. Hey MVC! The
model is made up any business objects that makes sense for the app and
usually a few service delegates. The View is your flash components and
composites of components. The Controller is the control dispatcher objs.
ActionScript is a powerful OO language. Strongly typed and offers a
brilliant event model though the Macromedia implementation is flawed.
Check out Grant Skinner's Gdispatcher for a better implementation. Below
I've included a base class I've created for making my remote service
delegates. It�s a good place to start. You will need Joey Lotts
NetServices as2 port and the Gdispatcher to get it working. If you have
any questions about structuring your actionscript classes or if anything
I said was too abstract let me know.
Enjoy,
Brian
/**
* RemoteService is a base class for creating
* Flash Remoting Delegates.
*
* @author Brian LeRoux, [EMAIL PROTECTED]
* @version 1.2
* @see mx.remoting.NetServices
* @see com.gskinner.GDispatcher
*
*/
import mx.remoting.NetServices;
import com.gskinner.GDispatcher;
class com.westcoastlogic.system.RemoteService
{
// GDispatcher methods
private var dispatchEvent:Function;
private var eventListenerExists:Function;
private var removeEventListener:Function;
private var removeAllEventListeners:Function;
public var addEventListener:Function;
private var _serviceName:String;
private var _servicePath:String;
private var _gw:NetConnection;
/**
* Constructor, should called via super().
*
* @param sn The service name.
* @param sp The service path.
*/
function RemoteService( sn:String, sp:String )
{
_serviceName = sn;
_servicePath = sp;
GDispatcher.initialize( this );
_gw = NetServices.createGatewayConnection( _servicePath
);
};
/**
* Private member.
*
* @return Returns the service.
* @throws Possible server Errors
*/
private function getService():Object
{
return _gw.getService( _serviceName, this );
};
/**
* Private member for dispatching _Status calls.
*
* @return void
*/
private function dispatchError( e:Object ):Void
{
var eventObj:Object = {
target :this,
type :"onError",
details :e.details,
code :e.code,
description :e.description,
level :e.level
};
dispatchEvent( eventObj );
};
private function setCredentials( u:String, p:String ):Void
{
_gw.setCredentials( u, p );
};
};
// and example usage:
// boy I'm giving away the farm here ;)
import com.westcoastlogic.system.RemoteService;
class com.westcoastlogic.GateKeeperDelegate extends RemoteService
{
private var username;
private var password;
function GateKeeperDelegate( sn:String, sp:String )
{
super(sn,sp);
};
public function login( u:String, p:String ):Void
{
username = u;
password = p;
authenticate();
};
public function logout():Void
{
setCredentials("","");
getService().logout();
};
private function authenticate():Void
{
getService().authenticate( username, password );
};
private function authenticate_Result(success:Boolean):Void
{
var event:Object = {};
event.target = this;
if( success )
{
event.type = "loginSuccess";
setCredentials( username, password );
}
else
{
event.type = "loginFail";
}
dispatchEvent( event );
};
private function authenticate_Status(e:Object):Void
{
dispatchError( e );
};
};
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Sean A Corfield
> Sent: December 5, 2003 6:31 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [CFCDev] Best Methodology/Framework for building RIA
>
>
> On Dec 5, 2003, at 2:03 PM, Jeremy Bruck wrote:
> > Thanks for your thoughts on Mach II. I think I will do it
> in Mach II
> > and
> > see what happens in the flash/flex world. I think this is
> the URL you
> > are
> > talking about for Sean's article on mm.com:
> > http://livedocs.macromedia.com/wtg/public/machiidevguide/
>
> That's the Mach II Development Guide but I think he was
> referring to my
> earlier article on fa�ades:
>
> http://www.macromedia.com/devnet/mx/flashremoting/articles/fac
ades.html
(I think - if not, go to the Developer Center, go into the Architecture
topic and it's the article on optimizing applications with design
patterns)
>> a better integration with flash in the future release.
Yes, I'm in two minds about that... Mach II provides an elegant MVC
solution in CF. When you build an RIA tho' at least part of the
controller needs to move into the Flash part of the application - you
move toward MVP (Model-View-Presenter) where the Presenter is
part-Flash, part-CF and acts as a controller-for-views in the Flash
part and as a controller-for-model in the CF part. That's why it's
tricky to graft Flash onto the front-end of Mach II - you really need
an ActionScript event handling system that then makes Remoting calls to
a specialized fa�ade on the Mach II application. Just my 2�...
Like Flash / Flash Remoting, Flex also requires a remote-CFC interface
to interact with ColdFusion so I suspect that similar concerns apply
for integrating Mach II with Flex, i.e., the problem is that Mach II
does not expose a Web Service-style API.
Sean A Corfield -- http://www.corfield.org/blog/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev'
in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[EMAIL PROTECTED]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev'
in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
