oh shit putting my foot in it now :P
Alright maybe need to explain a little more. From my original email.
init(datasource,table,pk)
getRecord(id) - gets single record
getColumnValue(id,field)
setColumnValue(id,field,value)
select(codition,ordering (optional)) - condition is where clause
count(condition (optional))
insertEmpty() - eg insert new record, return primary key
update(struct) - eg update record from form struct
delete(id) - delete record
So the init method gets passed in the datasource name, table name, and primary
key name. Now what this method does among other things is to query the database
table for the column names and puts the names and datatypes into a struct. You
need to get the column info so you can check the data retreival requests and
also to generate the update(struct) SQL code, etc.
So each table in your app is going to have an instance of this TableDAO, eg
if (NOT ISDefined("application.staffDAO") {
application.staffDAO = CreateObject('Component',path\tableDAO);
application.staffDAO =
application.staffDAO.init("staff","staffTable","userID");
}
Now the select(condition,ordering (optional)) method merely takes SQL clause
strings. eg
select("age <= 25 AND gender = 'F'", "FirstName,Surname")
will grab all eligible staff... err. nevermind :P
Basically my DAO is lazy and returns the entire records, not exactly efficient
especially in that case of using blob datatypes..
hope that clarifies a little,
Anyway, this has worked for me, its not complete. Like I said I dont handle
multiple tables yet but this has eliminated the vast majority of the trivial
SQL that i've had to write in the past.
TiM
-----Original Message-----
From: Raymond Camden [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 16 November 2004 9:20 a.m.
To: [EMAIL PROTECTED]
Subject: RE: [CFCDev] table DAO
Ok, so you don't like Doug's idea - but can you explain how you do filters
on the result sets then? Do you do it in the client? Do you pass filter info
to the dao?
===========================================================================
Raymond Camden, Director of Development for Mindseye, Inc (www.mindseye.com)
Member of Team Macromedia (http://www.macromedia.com/go/teammacromedia)
Email : [EMAIL PROTECTED]
Blog : www.camdenfamily.com/morpheus/blog
Yahoo IM : cfjedimaster
"My ally is the Force, and a powerful ally it is." - Yoda
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tim Van Der Hulst
> Sent: Monday, November 15, 2004 2:18 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [CFCDev] table DAO
>
> getAllActive()
> getByOwner( ownerID )
> getAllPrecedingDate( date )
>
> oh yep avoid that stuff like the plague. haha my early DAO's
> were like that before I realised all I needed was the one
> base DAO and the very occasional need to create a specialised
> subclassed DAO. Mind you in saying that I still haven't
> really tackled multiple tables/joins yet tho.
>
> TiM
>
>
>
> -----Original Message-----
> From: Doug Keen [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 16 November 2004 9:13 a.m.
> To: [EMAIL PROTECTED]
> Subject: Re: [CFCDev] table DAO
>
>
> > Ok then - so that brings up -another- question. getAll by
> itself, IS rare.
> > Most of the time I'm doing getAll where Active=1, or getAll where
> > Owner=Me, or some such. So if we have a Gateway CFC to
> handle getting
> > a bunch of crap, where do we put filters? That's business
> logic - and
> > it seems like it would make sense in the core CFC for the datatype.
>
> 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.
> ----------------------------------------------------------
> 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]
> ##
> ##
> ----------------------------------------------------------
> 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]
>
----------------------------------------------------------
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]
##
##
----------------------------------------------------------
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]
