Hi Justin, Re: the IBO, it is pretty simple. If you want to display a list of records, but some of the properties are calculated (or may be in the future, or for some other reason you want to use an object rather than just cfoutputting a recordset), the IBO is a simple performant solution. You¹d createobject an IBO, then you¹d myIBO.loadQuery(Recordset) to load a CF recordset into the IBO. You can then iterate through the recordset, using generic or custom getters.
<cfloop condition=²#MyIBO.next()#²> #MyIBO.get(³Title²)# - #MyIBO.get(³Price²)# </cfloop> If you have a getTitle() or getPrice() method, they¹ll be called. If not, the generic getter will pull the info from your recordset. You get: * The performance benefits of only having to instantiate a single bean even if you want to display 100 or 200 records. * The encapsulation benefits of an object (you can add a getPrice() after the fact to add business logic to calculating prices without affecting your view code which would still just call get(³Price²)) * A consistent pattern that you can use for all views if you so wish. As Joe Rinehart pointed out, there really isn¹t anything to the IBO it is just a couple of iterator methods, a generic getter and setter and a loadQuery() and loadStruct() method for populating data. That said, it¹s one of a small number of patterns I use consistently in my framework and I find it amazingly useful. Between that, my ORM, LightWire and some simple DSLs for describing rich CRUD operations and controller functions it allows me to create really rich custom web apps (excluding the HTML/CSS for the view and the project management/specification/data entry) in under a day. Best Wishes, Peter On 8/20/07 5:13 PM, "Justin Treher" <[EMAIL PROTECTED]> wrote: > Thanks for the responses - > > The main problem is that I¹m probably doing something wrong from the start, so > let me provide a little more info. > > My member class could be sorted in the database with no problem save for one > property. The membershipType property is an object. Therefore, if I want to > sort on membership type I¹m dealing with trying to sort an array of composed > objects. Perhaps I need to ease up on the only use arrays of objects in the > view? I tell you that it seems very complicated to have an entire object just > for one lookup value (membershipType). > > Here is an example of one instance in my array of members > firstName string > lastName string > membershipType members.membershipTypes.membershipType (example: > getMembershipType().getType()=volunteer) > > Right now I¹m returning objects to all of my tables and forms. I didn¹t think > I was supposed to work with queries in the view, only arrays of objects. I > could easily make a sortable query in the user gateway and do a query loop for > my output. Is this what you are suggesting? > > > Peter, I¹ve looked at your IBO and have to say that I¹m pretty unsure about > whether or not I should be using it. I don¹t know enough to understand if I > need it! > > > You are subscribed to cfcdev. To unsubscribe, please follow the instructions > at http://www.cfczone.org/listserv.cfm > > CFCDev is supported by: > Katapult Media, Inc. > We are cool code geeks looking for fun projects to rock! > www.katapultmedia.com > > An archive of the CFCDev list is available at > www.mail-archive.com/cfcdev@cfczone.org You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
