[trim] > > > layer was the layer that served both Mach-II and the Flash > > Client. I went the route of passing things like datasource > > as simple parameters on each call to the service layer. > > > > Are you saying if you want to implement a Flash client you > > would be implementing another layer/facade other than the > > service layer you have here? (If so, why?) > > For sure, I mean you could have it like this: > > Model | Manager | Service or FlashFacade | Flash Client > > > My thoughts would be to give flash one cfc to do all its "stuff with" - > purpose built, this way I can still abstract flash from my model (say I wish > to change managers around or swap stuff underneath around) while at the same > time not exposing my server-side "services/managers" to remote access. > Listeners in Mach-II kind of for me act as a pre-step before you get to the > Manager, its role is to listen for Mach-II specific events and as you know > delegate to various manager(s) if need be. I simply replace the Mach-II > Listener concept with FlashGatewayFacadeThingy concept and simply tell Flash > to look at that one object only (you could have many of them but most apps > could get away with just one). It takes information from Flash, interprets > its data and delegate to various services/managers. > > It's the way I personally would tackle it as then realistically you could > tie in "Flash Only" stuff if need be. While at the same time you could also > make as separate version specifically for WSDL? Yet your underlying logic > within Managers themselves aren't affected.. Its just another layer of > abstraction in the end. >
For me, the service layer served the HTML/Mach-II client as well as the Flash client. It was the Flash facade. It seemed to me to provide the most code reuse and reduce maintenance. I'm still not quite clear why you want to create another CFC just for flash. Even if you do have some "Flash only" functionality, those methods could still be in the service layer object, Flash calls it and Mach-II doesn't. -Phil ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words '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]
