In fact talking about this in this thread, I'm wondering if my "Bean"
(aside from probably being a bad label) is actually combining a bit of
a TO and a bit of a BO, and that may not be a good thing. I mean, I
know it works (I've used it), but I also strive to keep my knowledge
in line with the accepted industry standards. After looking at the TO
pattern at Sun's web site, I'm getting the impression that my concept
of a Bean doesn't match up very well with the patterns they list.

Just as an example, this is an example of how I might process,
validate, and persist some form data in a Fusebox 4.1 application.
This would use a TO and a BO and eliminate my "in-between-Bean", and
the BO would validate it's data from the passed TO. Anyone care to
comment on it? Barney, is this getting closer to the nomenclature that
you're familiar with?

<fuseaction name="storeContact">
        <invoke object="application.TOFactory"
                methodcall="newTO( 'contact', attributes )"
                returnVariable="contactTO" />
        <invoke object="application.BOFactory"
                methodcall="newBO( 'contact', contactTO )"
                returnVariable="contact" />     
        <if condition="#contact.validate()#">
                <true>
                        <invoke object="application.contactManager"
                                methodcall="save( contact )" />
                        <do action="success" />
                </true>
                <false>
                        <invoke object="contact"
                                methodcall="getErrors"
                                returnVariable="errorTO" />     
                        <do action="showContactForm" /> 
                </false>
        </if>
</fuseaction>
 


On 8/26/05, Peter J. Farrell <[EMAIL PROTECTED]> wrote:
> Brian Kotek wrote:
> 
> >To me a TO is basically a simple struct, but possibly wrapped up as a
> >CFC with public instance data. This would be just for moving data
> >around with no other functionality.
> >
> >
> Basically, this is the same for me - except I call the LTOs (lightweight
> transfer objects) as a distinction from java TOs.  I'll paste an example
> below:
> 
> <cfcomponent displayname="phoneTo"
>     output="false"
>     hint="A LTO that model the phone form.">
> 
>     <cffunction name="init" access="public" output="false"
> returntype="phoneTo">
>         <cfargument name="phone_id" type="numeric" required="false"
> default="0" />
>         <cfargument name="statuscode" type="string" required="false"
> default="" />
>         <cfargument name="phone_call_type" type="string"
> required="false" default="" />
>         <cfargument name="phone_number_type" type="string"
> required="false" default="" />
>         <cfargument name="phone_area_code" type="string"
> required="false" default="" />
>         <cfargument name="phone_number" type="string" required="false"
> default="" />
>         <cfargument name="phone_ext" type="string" required="false"
> default="" />
>         <cfscript>
>             this.Phone_id = arguments.phone_id;
>             this.Statuscode = arguments.statuscode;
>             this.Phone_call_type = arguments.phone_call_type;
>             this.Phone_number_type = arguments.phone_number_type;
>             this.Phone_area_code = arguments.phone_area_code;
>             this.Phone_number = arguments.phone_number;
>             this.Phone_ext = arguments.phone_ext;
>             return this;
>         </cfscript>
>      </cffunction>
> 
> </cfcomponent>
> 
> I feel that I gain a few things over a simple struct.  When init()ing a
> LTO, I can easily see what arguments I need
> 
> 
> --
> Peter J. Farrell :: Maestro Publishing
> 
> blog    :: http://blog.maestropublishing.com
> email   :: [EMAIL PROTECTED]
> ________________________________
> R O O I B O S  G E N E R A T O R...
> Create boilerplate beans and transfer objects for ColdFusion!
> Rooibos is free to use at: http://rooibos.maestropublishing.com/
> ________________________________
> Member of Team Mach-II - The next rev is coming...
> 
> 
> 
> ----------------------------------------------------------
> You are subscribed to cfcdev. To unsubscribe, send an email to 
> [email protected] with the words 'unsubscribe cfcdev' as the subject of the 
> email.
> 
> CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting 
> (www.cfxhosting.com).
> 
> CFCDev is supported by New Atlanta, makers of BlueDragon
> http://www.newatlanta.com/products/bluedragon/index.cfm
> 
> 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' as the subject of the 
email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting 
(www.cfxhosting.com).

CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm

An archive of the CFCDev list is available at 
www.mail-archive.com/[email protected]


Reply via email to