>On Mon, 15 Nov 2004 15:12:48 -0500, Doug Keen <[EMAIL PROTECTED]> wrote: > Often, in that situation, I'll actually create different methods for > different filtering options. For example, I may have a CFC with these > *public* methods: > getAll() > getAllActive() > getByOwner( ownerID ) > getAllPrecedingDate( date ) > > Those public methods would then simply relay the call to a *private* > method that contains the SQL and could have an interface like Tim > describes: > getAll( condition, order ) > > That way, you get the best of both worlds... the caller doesn't know > about the table structure, but your SQL code is isolated in a single > private method. The public methods simply relay the appropriate > information into the private method and return the results. >
I like the look of this particular idea. However, what happens when you have a very "flexiable" filter.. for instance. Lets say you have a bug tracking system. Each bug may (or may not) have any of the following attributes... status (open, closed, resolved, locked, etc) owner (person bug is assigned to) submitted by (person who submitted the bug) submitted date (date bug was created) category (bug, task, question, etc.) version (1, 1.1, 2, 2.1) milestone (release candidate 1, etc) area (database, user interface, documentation, web services, etc) now the user wants to see all open bugs assigned to him. you could call getAssignedByStatus(user_id,status) but then you might have get all open bugs assigned to bob for the next milestone and this could go on and on - leading you to having all sorts of method name permutations Or, you could have one big method that takes ina bunch of optional parameters and has a bunch of conditional inclusion of where clauses and outer joins etc.. to date this is the best option i Have found for such dynamic search mechanisims. Has anyone else found a better solution - and if so how you would reflect that either in a DAO or a Gateway? -- Bill http://blog.rawlinson.us ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at [EMAIL PROTECTED]
