> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]] On Behalf Of Phil Cruz
> > > Sent: Tuesday, 11 January 2005 1:56 AM
> > > To: [email protected]
> > > Subject: Re: [CFCDev] OO Concept - Crit Welcomed
[trim]
> > Yeah, I took onboard your sample code and some pattern research and
> > its what I came up with in the end. Mach-II has some really nice
> > example code and its execution has a nice element of
> simplicity behind it... Kudos.
> >
>
> Did you mean Mach-II.info has some nice sample code?
>
For sure, I freely admit it was my first real-world benchmark for coding in CFMX patterns such as DAO/DG etc. It put a visual representation to what I had been reading. I liked it anyway.
[trim]
>
> I agree that for interop via web services you want to avoid
> passing complex objects. That's why I questioned the
> configBO. In the Mach-II.info implementation, the service
Purpose of configBO was simply to store all these nitty "Config.XML" settings inside an object for further use. In that, I noticed with a very large majority of my code that they follow similar patterns in application design - being that the nature of coldfusion it requires information such as:
- how do I connect to a database? What's its name and is it secured / unsecured connection
- if I can an image upload or any upload, where is the base path in which I store it? (ie one api for all)
- email settings what are they? And which ones should I use for this specific application
- other... (insert another generic setting information).
I conjured this object mainly because I can see in some parts an overlap in information requirements? Example comes to mind where you may have a mass mailout. Now typically your manager will need to know Email Settings, Query Settings (to farm out email address to give to emailObject etc) as well as fileLocations (ie say you want to also check for spooling blockage - just in case scenario).
It's a timid example but what I'm trying to illustrate is that rather then passing in various arguments per manager you could legitimately have an object that you pass in (sort of an uber serialized format). It could then take on some business specifics in that before its handed to the manager you could require it to validate its settings (ie email server is down, can't use it, throw exception immediately as it's a critical problem). Stuff like that - you *could* tie down into the email Object(s) themselves before send out? I dunno, I feel it was more suited inside a config object when you set it.. As that's where it kind of needs to throw such exception ("oops you gave me wrong server dude, rethink and try again") ... Does all that hold substance - I have no idea..
> 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.
Scott.
http://www.mossyblog.com
P.S
(You could even make Flash Mimic Mach-II in that what really is the difference between a Mach-II based screen change and a flash one? An event is triggered, a set of instructions are read and a page is built. You could purpose build your flash screen to follow that same suite - ie CFMX could send back a bunch of instructions similar in style to Flash where it could present the screen in a similar way... Only has more "state" capabilities hehe...
Oooer.. Maybe we should build "Flash Mach-II".... Or not.
