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]
