In case you are ever looking for generic sorting code - http://cflib.org/udf.cfm/quicksort
It takes a comparison UDF as an argument, so you can customise how you want things to be sorted as much as your heart's content. :oD Mark On 8/21/07, Peter Bell <[EMAIL PROTECTED]> wrote: > > 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 -- E: [EMAIL PROTECTED] W: www.compoundtheory.com 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
