What I have found is that with my flash apps, I need to have a 'flash to obj' layer that performs the following functionality.
Struct to Object, or Object to Struct. By this I mean that flash cannot receive an instance of a cfc, making a cfcs method unavailable. Basically, flash passes in a sturct that i use to build my objects with, which then gets passed around the application to various listeners such as printers, persistors, etc. Then when I pass back info to a flash app I have to flatten my object into a srtuct and send it. Kind of a bummer...and I was just wondering if I should even worry about building the objects...can someone help me justify my gut feeling to worry about them? My current arguments are future flexibility, tighter application control, and ability to encapsulate more functionality. Anything else....its hard to recognize the benefits where deadlines are looming =) Thanks, Justin -----Original Message----- From: Sean [mailto:[EMAIL PROTECTED] Sent: Thursday, September 11, 2003 5:03 PM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] DB and OO question I was referring to your method as being one that would work. In terms of my extra layer *translating* and *interpretive* can be used interchangeably. In my case and point the interpretative layer happens to be Mach II. It is the translator between my object layer and the view layer. However had Flash been the UI, I would have probably created a layer of CFC acting as go between my Flash UI and the object layer. HTH Sean Kubeworks, LLC We focus on technology so you can focus on your customers. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brad Howerter Sent: Thursday, September 11, 2003 5:30 PM To: '[EMAIL PROTECTED]' Subject: RE: [CFCDev] DB and OO question >>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)! You can't write a >>'DrawThySelfAsAFlashForm' method in a CFC very easily... > > That would work as well. My aim is to separate the view layer from my > object layer by creating a *translating* layer. It might seem like more > upfront cost, but I think the payoff is in the flexibility. If anything > within the view changes I am not touching my object layer and thus > taking a risk at breaking the app. What would work as well? What do you mean by 'translating' layer? > >>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, I just have to >>identify the properties. But I will concede that they shouldn't be >>used >>much, and I'll try to not use them. > > How do you include this core.cfc into other CFCs? I do like the idea of > having a general set/get method. Every cfc that doesn't already inherit something inherits core.cfc. I set this up before MX had the component.cfc feature (which does this automatically). *** The information in this email is confidential and intended solely for the individual or entity to whom it is addressed. If you have received this email in error please notify the sender by return e-mail, delete this email, and refrain from any disclosure or action based on the information. **** ---------------------------------------------------------- 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] ---------------------------------------------------------- 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] ---------------------------------------------------------- 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]
