> set/getHeader
> set/getRecordset
> set/getFooter
> set/getTitle
> set/getColumnOrder
I'm a little scared by a slew of get/sets-- I know this is the
recommended way w/ cfmx but sometimes it makes me wonder if an actual
object is being modeled or just properties. For example, in a shopping
cart I *could* have set/getTitle, set/getProductArray, etc... But I find
all any other obj's communicating to my cart instance really need is
getCart(), add(), remove(), clear(). I'm not saying what your doing is
wrong; just something to look for. Try making the methods more genuine
to how the object would be interacted with in "the real world".
> I've got a "ReportManager" which adds a persistence option
> when invoking the Report. i.e. The report may be created for
> a CSV dump or rendered as a pageable recordset for use in
> HTML display.
Nice
> Where I'm stuck is how to properly model the database query.
> I was planning on extending this generic Report object for
> each report type we require. Each subclass would most likely
> contain a method or two that deal strictly with excuting the
> SQL or proc and populating the "recordset" property of the
> Report object in question. (this make
> sense?)
Yeah this part sounds fine to me. In most cases I'm finding there are
either one or two database interaction methods. Usually one for
instantiation and when needs be one for updating. Strange but I don't
think I've modeled an obj that has an explicit database delete method.
*shrugs*
> If this is a sound approach...I'm wondering if I can have the
> ReportManager accept a "reportType" as a parameter and have
> it dynamically formulate the target subclass as follows:
>
> CreateObject("component","com.terrapayments.reports.#arguments
> .ReportTyp
> e#").init()
>
> This way I can add a new report just by dropping in a new
> subclass of Report and not have to touch any other components
> going forward.
I think that's a totally good idea for a factory type component.
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the word '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 www.mail-archive.com/[EMAIL PROTECTED]
