Remember that not everything needs to be shoe-horned into a
Cairngorm provided class. I'm going to discuss around a few issues here,
and hopefully coalesce a point by the end.
First of all, the front controller will tyipcally listen
for *user* gestures; button clicks, drag and drops, menu selections, etc.
However, when we've been building applications with server-push, or
collaborative appliations where one instance of an application wishes to change
the state of another running instance, we've certainly broadcast Cairngorm
events to our front controller.
Hold that thought.
Next - the ServiceLocator is really a repository for RPC
services, it doesn't have to be where you encapsulate your XML Binary
sockets. I'd consider that you create a class of your own devising,
that encapsulates everything about the XMLSocket - it opens the socket, stuffs
data down it and handles the responses. We've often called these classes
"bridge" classes, but you may call them adapters, facades, proxies, services ...
let's not get religious about naming. Your business delegate classes could
use your "bridges", and once again the business delegate is making use of a
different type of service, but hiding the use of that service from the command
classes.
Your "bridge" class could then more elegantly mutate
low-level events (such as dataReceived) into higher-order events (such as
QuoteController.STOCK_PRICE_UPDATED) that are broadcast to the
front-controller. I feel funny about the ServiceLocator broadcasting these
events - it smells like the wrong class responsibility to me, which is an
indication of the Extract Class refactoring just waiting to happen (http://www.refactoring.com/catalog/extractClass.html)
You may decide to hide the location details of the XML
socket into the ServiceLocator - let's leave that as an exercise in readability
and maintainability that you decide.
So there are many ways to solve this; but I think
encapsulation of the XMLSocket comms into a separate class and mutation of
protocol-specific events into application-specific events, would be good
guideline principles in deciding upon your own design.
Good to see you guys all
pushing Cairngorm in these new and exciting ways; if this becomes more common
use-case for Flex 2.0 development, then we can consider some of your solutions
as candidate infrastructure or
recommendations.
Best
wishes,
Steven
|
Alex,
Do you think this approach would apply to socket connections as well. E.g. XMLSocket, or Binary Sockets?
My issue is that these socket connections would need to broadcast dataReceived() events. These should be caught by the FrontController, correct? Does it make sense for the ServiceLocator to be broadcasting such events?
Scott
--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
YAHOO! GROUPS LINKS
- Visit your group "flexcoders" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
