Remoting is easier to implement and may have an edge in performance (binary format vs XML) but that may not be big difference if you use http compression. I like WS because it's an open standard and so clients other than Flash can play. Also, you could build your backend in BlueDragon since that supports WS. Just depends on your needs.
-Phil On Tue, 25 Jan 2005 15:05:51 -0500, Ken Dunnington <[EMAIL PROTECTED]> wrote: > Thanks Bill (and good call, Phil!) :) That distinction does make > sense, and I recall reading something similar about mementos when I > first started researching design patterns many months ago. I had > thought about using web services instead of remoting, but from what > I've read, remoting does have a performance advantage (and is simpler > to implement) so I decided to go that route. So I'm still not 100% > sure what to call it (probably a transfer object) but for Flash > Remoting I'm going to use a struct that is comprised ot the object's > instance variables. > > Now I have to see if Flash can handle structs of structs :) > > On Tue, 25 Jan 2005 13:42:33 -0500, Bill Rawlinson > <[EMAIL PROTECTED]> wrote: > > well i can't help but pipe in here but I thought a book I have on hand > > might help clear up the memento issue as I think the author explains > > it quite nicely. > > > > an object is used as a "souvenir" that only has value to the original > > holder and helps it remember a previous state. > > > > He also states that a memento should not be readable by anything buts > > its originator. In fact other objects that receive a memento > > shouldn't care what is in it - only that they should trust that it is > > sufficient data to return the originator back to a prior state. > > > > Bill > > > > > > On Tue, 25 Jan 2005 10:03:07 -0800, Phil Cruz <[EMAIL PROTECTED]> wrote: > > > If you're using Flash Remoting there may not be an advantage to > > > passing a CFC as opposed to a struct. In my case, I was using web > > > services and I think a CFC with <cfproperty> tags allowed for better > > > interoperability. > > > > > > I can't eloquently describe the difference between TO and memento but > > > it's been discussed before so search the archives (CFCDev, Mach-II > > > list, Mach-II forums) and you'll get a lot of info. Or just wait a > > > bit and we'll probably get a few posts on that ;) > > > > > > -Phil > > > > > > On Tue, 25 Jan 2005 12:42:06 -0500, Ken Dunnington > > > <[EMAIL PROTECTED]> wrote: > > > > Phil, that's essentially what I'll be doing, except in order to avoid > > > > writing more objects than I really need, I gave all my beans a > > > > getMemento() method which returns the (local) instance data as a > > > > struct. Is there any advantage to using a full-blown object (even a > > > > simple one like that) when all you'll be doing with it is reading > > > > data? My DAO does all the setting using setter methods. In any case, > > > > from what I can discern, Flash still wouldn't know what to do with a > > > > transfer object, though I could be wrong. :) (Flash Remoting can > > > > handle Actionscript objects which are very similar to what you posted > > > > above.) I've never quite gotten the difference between a transfer > > > > object and a memento, actually, except that a memento is supposed to > > > > be serializable, I believe. > > > > > > > > > > > > On Tue, 25 Jan 2005 09:27:43 -0800, Phil Cruz <[EMAIL PROTECTED]> wrote: > > > > > I wanted to treat the data as "public" and avoid having to call > > > > > getters/setters on the transfer objects. For regular BOs, I don't use > > > > > this and do call getters/setters, in general. > > > > > > > > > > Again, practice falls under the definition of the TO per Sun > > > > > "Typically, the members in the Transfer Object are defined as public, > > > > > thus eliminating the need for get and set methods." > > > > > > > > > > I don't see it a a thread-safe problem because I am explicitly making > > > > > the data "public". > > > > > > > > > > -Phil > > > > > > > > > > On Tue, 25 Jan 2005 12:05:59 -0500, Peter J. Farrell > > > > > <[EMAIL PROTECTED]> wrote: > > > > > > Phil- > > > > > > > > > > > > I'm curious why you are using the "this" scope and not a locally > > > > > > declared var'ed variable? I'd think the code below isn't > > > > > > thread-safe at > > > > > > all.. > > > > > > > > > > > > Something like: > > > > > > .... > > > > > > <cfscript> > > > > > > var stLocal = StructNew(); // local struct > > > > > > stLocal.userID = arguments.userID; > > > > > > stLocal.userName = arguments.userName; > > > > > > ... > > > > > > ... > > > > > > return stLocal; > > > > > > </cfscript> > > > > > > ..... > > > > > > > > > > > > .Peter > > > > > > > > > > > > Phil Cruz wrote: > > > > > > > > > > > > >You can't return full blown BOs but you can return CFCs that wrap > > > > > > >the > > > > > > >struct as a "transfer object". For example I have implemented TOs > > > > > > >like this > > > > > > > > > > > > > > > > > > > > ><cfcomponent access="public" displayname="UserTO" hint="Tranfer > > > > > > >Object"> > > > > > > > <cfproperty name="userID" type="numeric" /> > > > > > > > <cfproperty name="username" type="string" /> > > > > > > > <cfproperty name="email" type="string" /> > > > > > > > <cfproperty name="password" type="string" /> > > > > > > > <cfproperty name="password2" type="string" /> > > > > > > > <cfproperty name="firstName" type="string" /> > > > > > > > <cfproperty name="lastName" type="string" /> > > > > > > > > > > > > > > <cffunction name="init" access="public" returntype="userTO" > > > > > > >output="false" displayname="UserTO Constructor" hint="I initialize > > > > > > >the > > > > > > >TO"> > > > > > > > <cfargument name="userID" type="numeric" > > > > > > > required="false" default="0" /> > > > > > > > <cfargument name="username" type="string" > > > > > > > required="false" default="" /> > > > > > > > <cfargument name="email" type="string" > > > > > > > required="false" default="" /> > > > > > > > <cfargument name="password" type="string" > > > > > > > required="false" default="" /> > > > > > > > <cfargument name="password2" type="string" > > > > > > > required="false" default="" /> > > > > > > > <cfargument name="firstName" type="string" > > > > > > > required="false" default="" /> > > > > > > > <cfargument name="lastName" type="string" > > > > > > > required="false" default="" /> > > > > > > > > > > > > > > > > > > > > > <cfscript> > > > > > > > this.userid = arguments.userID; > > > > > > > this.username = arguments.username; > > > > > > > this.firstName = arguments.firstName; > > > > > > > this.lastName =arguments.lastName; > > > > > > > this.email = arguments.email; > > > > > > > this.password = arguments.password; > > > > > > > this.password2 = arguments.password2; > > > > > > > return this; > > > > > > > </cfscript> > > > > > > > </cffunction> > > > > > > > > > > > > > ></cfcomponent> > > > > > > > > > > > > > > > > > > > > >(http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html, > > > > > > >" It is a design choice as to whether the Transfer Object's > > > > > > >attributes > > > > > > >are private and accessed via getters and setters, or all the > > > > > > >attributes are made public.") > > > > > > > > > > > > > > > > > > > > >-Phil > > > > > > > > > > > > > >On Tue, 25 Jan 2005 10:11:55 -0500, Ken Dunnington > > > > > > ><[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > >>Right, I'm building the Flash interface for my model, which I've > > > > > > >>also > > > > > > >>plugged into Fusebox (mainly for learning, but I'm also using it > > > > > > >>for > > > > > > >>the HTML admin interface.) > > > > > > >> > > > > > > >>Thanks for the info! I will narrow down what methods Flash will > > > > > > >>need > > > > > > >>and build them into the facade. I was under the impression Flash > > > > > > >>could > > > > > > >>deal with object references, though. That's too bad, it kind of > > > > > > >>breaks > > > > > > >>down encapsulation (no more beans!), but all my bean objects have > > > > > > >>memento methods, and I know Flash can deal with structs. > > > > > > >> > > > > > > >> > > > > > > >>On Mon, 24 Jan 2005 14:13:52 -0800, Barney Boisvert <[EMAIL > > > > > > >>PROTECTED]> wrote: > > > > > > >> > > > > > > >> > > > > > > >>>Any method called from the Flash movie must be declared remote. > > > > > > >>>Methods that the remote methods call do NOT have to be remote. > > > > > > >>> > > > > > > >>>Now as for how you're using the methods, I don't think you can > > > > > > >>>do what > > > > > > >>>you've listed. Flash, to my knowledge, can't deal with object > > > > > > >>>references, it can only deal with "normal" data types > > > > > > >>>(primatives, > > > > > > >>>arrays, structs). Your model needs to have a layer of > > > > > > >>>encapsulation > > > > > > >>>so that you can only deal with those data types from flash. For > > > > > > >>>example, you might have a getProduct(productID) method in your > > > > > > >>>remoting facade, which would then do the method chain you listed > > > > > > >>>and > > > > > > >>>pass the result back. > > > > > > >>> > > > > > > >>>Also, just to clarify things, you're not building a remoting > > > > > > >>>interface > > > > > > >>>to a FB4 app, you're building a data model that is used by your > > > > > > >>>FB4 > > > > > > >>>app, and by the remoting facade, right? Because if you're > > > > > > >>>trying to > > > > > > >>>wrap an actual FB app in a remoting facade, you're going to have > > > > > > >>>all > > > > > > >>>kinds of issues down the road. > > > > > > >>> > > > > > > >>>cheers, > > > > > > >>>barneyb > > > > > > >>> > > > > > > >>>On Mon, 24 Jan 2005 17:04:40 -0500, Ken Dunnington > > > > > > >>><[EMAIL PROTECTED]> wrote: > > > > > > >>> > > > > > > >>> > > > > > > >>>>I'm about to start testing/implementing a Flash Remoting > > > > > > >>>>interface to > > > > > > >>>>an application I'm building in Fusebox 4.1 (I figured, why make > > > > > > >>>>it > > > > > > >>>>easy on myself, I should just dive into two new areas at once! > > > > > > >>>>:)) > > > > > > >>>>I've built most of my model and am about to start on the gateway > > > > > > >>>>object that I plan on using as the interface to my application > > > > > > >>>>for > > > > > > >>>>Flash (please excuse my misuse of the term 'gateway' here.) > > > > > > >>>> > > > > > > >>>>In my model, most of my methods are declared "public" but I > > > > > > >>>>know for > > > > > > >>>>Flash you need to declare your methods "remote" so here's where > > > > > > >>>>my > > > > > > >>>>question comes in. My model does a lot of reference passing > > > > > > >>>>when it > > > > > > >>>>comes to objects, stuff like productManager.getDAO() and the > > > > > > >>>>like, so > > > > > > >>>>I can more easily swap out components if needed. If I pass a > > > > > > >>>>component > > > > > > >>>>reference to Flash this way > > > > > > >>>>(flashInterface.getProductManager().getDAO().fetch(productID) > > > > > > >>>>for > > > > > > >>>>example) will this work, even though all the methods on > > > > > > >>>>productDAO() > > > > > > >>>>are public, and not remote? I really don't want to implement > > > > > > >>>>every > > > > > > >>>>possible method within the Flash interface object, wrapping > > > > > > >>>>other > > > > > > >>>>method calls around remote method declarations. :) > > > > > > >>>> > > > > > > >>>>Any help is greatly appreciated! > > > > > > >>>>Thanks, > > > > > > >>>>Ken > > > > > > >>>> > > > > > > >>>> > > > > > > >>>-- > > > > > > >>>Barney Boisvert > > > > > > >>>[EMAIL PROTECTED] > > > > > > >>>360.319.6145 > > > > > > >>>http://www.barneyb.com/ > > > > > > >>> > > > > > > >>>Got Gmail? I have 8 invites. > > > > > > >>>---------------------------------------------------------- > > > > > > >>>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] > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >---------------------------------------------------------- > > > > > > >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] > > > > > > > > > > > ---------------------------------------------------------- > > > > > 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] > > > > > > > ---------------------------------------------------------- > > > 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] > > > > > > > > > -- > > [EMAIL PROTECTED] > > http://blog.rawlinson.us > > > > I have 9 gmail invites,want one? > > ---------------------------------------------------------- > > 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] > ---------------------------------------------------------- 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]
