Good point. Flash won't call methods that return (or output) HTML, so they
wouldn't have to change. But you would have to add some getter methods (if
you've taken Holub's advice to get rid of them)!
Right, mostly Flash will call methods that return 'lumps' of data that the Flash UI will need to render everything. That's mostly using the Value Object design pattern. See this article for more on Flash, CF and design patterns:
http://www.macromedia.com/devnet/mx/flashremoting/articles/facades.html
The same approach can be used for communication between the model and the views in a Mach II application - just as an example.
I'm not going to get rid of my getter/setter methods, but mine are defined
in my core.cfc (as get('property') and set('property', value) ), so it seems
one of Holub's arguments against them don't apply in my case: I don't have
added complexity because I don't have to write any code
Except that having generic property accessors like that breaks encapsulation even more (since client code can access *any* instance data!).
I just read Holub's article. Applied to ColdFusion MX, I think it is a
good
argument to encapsulate more of your data access within CFCs, including
writing methods to do display instead of retrieving values to display on
your own. Once you put the display methods in your CFCs, then you can
dispense with the setter/getter methods. Holub says "Draw Thyself".
You're missing a very important point in his article tho'. He says:
"Bear in mind that I haven't actually put any UI code into the business logic. I've written the UI layer in terms of AWT (Abstract Window Toolkit) or Swing, which are both abstraction layers. The actual UI code is in the AWT/Swing implementation. That's the whole point of an abstraction layer—to isolate your business logic from a subsystem's mechanics. I can easily port to another graphical environment without changing the code, so the only problem is a little clutter. You can easily eliminate this clutter by moving all the UI code into an inner class (or by using the Façade design pattern)."
'drawThyself()' doesn't generate HTML. To map his scenario to web applications and CF you'd need an HTML UI layer that applications called into in order to render pages - you wouldn't have HTML fragments in your 'drawThyself()' methods.
Sean A Corfield -- http://www.corfield.org/blog/
"If you're not annoying somebody, you're not really alive." -- Margaret Atwood
---------------------------------------------------------- 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]
