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]

Reply via email to