RE: [CFCDev] Bean and CFC question

[Jim Davis]

I guess that’s where I’m having my disconnect here – why would my (or Hals or Sean’s or whomever’s) solution necessarily mean that the code is harder to maintain while dedicated getter/setter method mean it’s easier?   Honestly I see very little difference.   In my case documentation was one of the key requirements: I do not think that CF offers very good introspective documentation methods so I wrote my own.  Although I use generic getter/setter methods they don’t see to have much to do with documentation or maintenance efforts.  Rather the method for defining and maintaining properties does – if you use getter/setter methods to do that, great, if not then you have to do it in some other way – but as long as its done I’m not sure what the problem is.   In both cases you’re predefining the properties of the component so in both cases you can use that definition to document those properties.  In short I don’t think that either method is inherently “good” or “bad” at documentation – you have to go the extra mile and make sure do it yourself no matter which method you use.   I’m quite pleased with my self-documentation system.  If you take a look at the component catalogs here:   http://www.depressedpress.com/Content/Development/ColdFusion/DPLibraries/Index.cfm   Realize that each entry in the component catalog is generated dynamically from the component metadata (with additional information provided by custom <dodoc> tags embedded in the component).  Here’s the tutorial page that goes through how to do this:   http://www.depressedpress.com/Content/Development/ColdFusion/DPLibraries/Articles/Tutorial_DPCFCs/DPDocs.cfm   Ignoring any extra tags the components still self-document all properties (along with access and type information) and methods.  With the dpdoc information they can also document anything you wish: I document method return and exception information as well and authorship, versioning, datetime stamps, etc.   While my actual tutorial and system-level document is definitely lacking I really don’t think I can be faulted for my CFC documentation.  ;^)   Jim Davis ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org