What are the reasons for NOT having methods that return HTML strings as a result? All I ever read is "It's stupid" or "It's bad".
IMO, it is not inherently stupid or bad. It may be limiting, but most choices are to some extent.
And I don't see a downside to it. If I have, say, a person object, why shouldn't it know how to display itself?
This reduces the capability of your person object quite a bit. As soon as your object understands how to display itself, then you must settle for either having it display in a single way or continuously updating it for each new display you'd like:
1) you can't/shouldn't output html to Flash, so your person object rules out Flash or must be updated to allow for Flash when you decide Flash is worth it.
2) you shouldn't put formatting in your html output, because then when the thirteenth redesign gets issued by marketting you'll need to go back to your code and change all the <b>'s to <i>'s. This may be alleviated somewhat by a strong CSS implementation.
3) in most of my experience, deciding to have display methods in my objects then forbids me from centralizing display/design code elsewhere -- for example, creating an HTML gateway (er, "website"), a Webservices gateway, and a Flash gateway, all of which use the same person object.
If you have few objects, this may not be a big deal. But if you have a dozen or two or a hundred objects...
--
Ben Curtis
WebSciences International
http://www.websciences.org/
v: 310 478 6648
f: 310 235 2067----------------------------------------------------------
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]
