> 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 hear ya...and after pondering for some time I figured in this case it'd be worth it. For instance, my CSV object needs to access different properties of the report for placement within the document...or in some cases, omit them altogether if they have no length. Thanks for comments! Stace -----Original Message----- From: Brian LeRoux [mailto:[EMAIL PROTECTED] Sent: October 9, 2003 1:57 AM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] Modeling CFCs, basic example Part II > 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] AVIS IMPORTANT: ------------------------------- Les informations contenues dans le present document et ses pieces jointes sont strictement confidentielles et reservees a l'usage de la (des) personne(s) a qui il est adresse. Si vous n'etes pas le destinataire, soyez avise que toute divulgation, distribution, copie, ou autre utilisation de ces informations est strictement prohibee. Si vous avez recu ce document par erreur, veuillez s'il vous plait communiquer immediatement avec l'expediteur et detruire ce document sans en faire de copie sous quelque forme. WARNING: ------------------------------- The information contained in this document and attachments is confidential and intended only for the person(s) named above. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution, or any other use of the information is strictly prohibited. If you have received this document by mistake, please notify the sender immediately and destroy this document and attachments without making any copy of any kind. ---------------------------------------------------------- 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]
