Nope if you don¹t like them, just remove them from the IBO it¹s a sample code pattern I¹d expect some people to remove the generic getters and setters, others to change the iterator to have an explicit hasNext() method it is a concrete example of code used to illustrate the general pattern you¹ll probably want to tweak the code to make it ³yours².
Best Wishes, Peter On 8/20/07 5:50 PM, "Justin Treher" <[EMAIL PROTECTED]> wrote: > Regarding the IBO, does that require me to use generic getters and setters? > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Bell > Sent: Monday, August 20, 2007 5:41 PM > To: cfcdev@cfczone.org > Subject: Re: [CFCDEV] Sorting Objects > > 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 > > 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
