Well, without further reading, I'm going look confused with the below subclass stuff, Patrick. (so imagine a confused look). I did read Joe's article earlier today coincidentally enough.
However, the membership type table has to be managed as well with its own CRUD. So, it is nice to have that setup within my model as an object. My database has a member table, a membership type table, and a lookup table for the two. The lookup table is not represented by an object, so at least I have that part down. I have the query thing working now. So, certain parts of the app, the lists and tables, are getting data from the queries, while the forms are getting objects. I'll have to investigate the IBO further. A final note, how do you all handle cfmail tags. Do you have them in your view called by the controller? I put together a mailer service in the model, but I'm not sure if that is correct or how to expand on that. Justin -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick McElhaney Sent: Monday, August 20, 2007 8:47 PM To: cfcdev@cfczone.org Subject: Re: [CFCDEV] Sorting Objects On 8/20/07, Justin Treher <[EMAIL PROTECTED]> wrote: > My object is composed of another subject (member class has a > membershipType class). That doesn't sound very object-oriented to me. Would it make sense to have an abstract class, member, and have each membership type be a subclass of member? (See Joe Rinehart's excellent article on not letting the relational model drive the domain model: http://tinyurl.com/2kqg4z) 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
