|
Not sure this quite works for FDS. Because the instance of
the DataService that we have on the client side has special properties that let
us know what is happening with that data service. So we need to use the
DataService instance in various places in the application in order to get things
done.
Right now I am hanging my DataService instance on one of my
models, and everything works great. I am only looking to make things a bit
cleaner.
Perhaps what you mentioned below works best for the Flex
Messaging portion.
Dimitrios Gianninas
RIA Developer
Optimal
Payments Inc.
From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of JesterXL Sent: Tuesday, July 11, 2006 11:29 PM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Cairngorm ServiceLocator and FDS
This one's long!
Before I gave up on FDS, I had a few ideas that
seemed to work, but were unforunately only 50% implemented in
Cairngorm.
As people are finding, Cairngorm works great for
the request / response model, but the push model, you go... wtf?
I've used the same ideas with Flash Media Server,
which is also push, and it seems to hold. Additionally, because there is a
significant amount of logic that happens in the actual process of pushed
messages, everything from simple routing, message context creation (think
Messages that are ValueObjects), and actual events that happen, a whole other
class set really helps.
Here's a diagram of the circular pattern described
below.
I used an Observer pattern. Basically,
one class "watches" the Consumer and Producer services. These exist in the
ServiceLocator. They, like Delegates, get the service from that
class. Cairngorm handles the sends and even has the Delegate's handle the
acknowledge messages. The Observers handle the pushes. Basically
Cairngorm handles the Producer, the Observer class(es) handles the
Consumer.
Cairngorm is damn good at the Producer since it
technically is a request / response. "Please send the message. Ok,
it sent."
The Observer, however, is kind of weird. It
extends a base class. This is done for 2 reasons. First, it
abstracts away the access to the ServiceLocator. Second, it also abstracts
away the onMessage; this is a protected method that is called for you with the
event passed in. Extending this class allows you to add context and not
worry about plumbing.
For example, if you are connecting to a simple
chat channel in your FDS that deals mainly with text based messages, you'd
extend the ObserverAbstract to be "ChatObserver" or something to that
effect. It's onMessage handler would process all messages that came
in. Based on their headers & body, he'd know what type of things to
look for, in this case chat specific messages; "someone joined", "someone sent a
private message to you", etc. Because this class is specific to those
types of messages, it can ignore the rest. This also allows the creation
of other Observers that do specific things for specific channels.
There is one additional thing, though, that these
Observers can do. They too can dispatch events! This means they can
do the same thing everything else in the Cairngorm world can do; dispath Events
to run Commands to modifiy data in the ModelLocator. In this case,
updating chat text, showing a new private chat window, etc.
The modification to ServiceLocator is minimal; you
add the method, and put the destination inside as a constant.
Cairngorm's Delegate's then send messages via the
Producer, begotten from the ServiceLocator, and fire their onResults when they
get a successful Acknowledge message.
The setup goes something like this; you add just
one extra tag:
<business:Services id="dataServices"
xmlns:business="com.jxl.project.bizznass.*"
/>
<control:Controller id="controller" xmlns:control="com.jxl.project.controller.*" /> <observers:LobbyObserver serviceName="jxlConnection" /> You should recognize the top 2; they're used in
your Application class. The 3rd one is the Observer. Works pretty
well.
....now, for the record, my boss hates this.
While he likes the Observer part, and digs how Observers can also fire off
Commands via Events, he doesn't like how I've created them. There are some
other tight coupling things he mentioned too, but I can't remember them right
now. Bottom line is, one of his many ideas was to have a stateful (read
"not stateless") Command actually create the Observer instead of the
Application. You can then initiate this via an Event class as
regular. Events could have the Command handle calling
methods on the Observer, much like regular Commands call methods on the
Delegate.
I didn't like the thought of a
stateful Command, but I totally understood how his ways, which were better
described by him than me, were less coupled, and more integrated into Cairngorm
as a whole. The whole "Observer fires callbacks on the
Command that never dies" was kind of neat, though. :: shrugs :: We only
talked for a total of 4 minutes over 2 days, so those were just our initial
ideas.
I haven't had time to fully test them out more
since I've fallen more into the GUI design realm as of late. Hopefully
these ideas spark more and/or better ones or discussion at least.
----- Original Message -----
From: Dimitrios Gianninas
Sent: Tuesday, July 11, 2006 9:22 PM
Subject: RE: [flexcoders] Cairngorm ServiceLocator and
FDS Also, how have people handled DataService responses?
Unlike RPC, DS has 4 events: result, fault, conflict and
message. Can't use the regular Responder interface in Cairngorm, so I created a
DataServicesResponder interface.
Dimitrios
Gianninas
RIA Developer
Optimal
Payments Inc.
From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Dimitrios Gianninas Sent: Tuesday, July 11, 2006 9:05 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Cairngorm ServiceLocator and FDS
Glad to see I'm not crazy :) With this thread this
afternoon, I was like "oh ya, I still need to clean my DataServices code and put
it in the ServiceLocator". And then I started the work and was like, how is
this going to work, a DataService ain't so simple as RPC services. As you noted
below it is much more "smart" since it has properties like 'commitRequired' and
'mergeRequired'... in my app those property are binded to controls to provide
visual feedback to the user.
So my first thought was to wrap it in some class... like a
delegate, but seems redundant, so still thinking....
Dimitrios
Gianninas
RIA Developer
Optimal
Payments Inc.
From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Steven Webster Sent: Tuesday, July 11, 2006 5:32 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Cairngorm ServiceLocator and FDS
Hey Mike,
So that's an interesting question you ask; our intention
for ServiceLocator is support for the RPC services in Flex ... at least that is
the heritage of the ServiceLocator from Flex 1.5, and that's how we've
personally been using it in Flex 2.
For the Flex Data Services apps that we're building, we're
still chewing around on a number of different approaches, and haven't yet
reached a conensus on what we consider "bestest-practice"; there are so many
different use-cases.
My instincts are that data services don't need to be
declared on the ServiceLocator, and that managed collections are more akin to
"intelligent model" objects; that if a command is used to manipulating a
model (via the model locator) onResult of an RPC call, it makes sense in the
data services world that a Command no-longer needs asynchronous result handlers,
but can instead optimistically manipulate a model (a collection with data
services) within the execute() method of a command. So a command still
updates the model, and binding notifies the view - so the "MVC" approach we
achieve in Cairngorm still holds.
This then begs the question of where you
define/create/initialise/etc your collections; is that the ServiceLocator, or is
it somewhere else. Jury is still out for me.
I'm as keen to hear your thoughts as you may be to hear
ours. It still "feels" right to me that the ServiceLocator remains "RPC
only", but I can be convinced with a good argument.
Thoughts ?
Steven
-- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
SPONSORED LINKS
YAHOO! GROUPS LINKS
|
- RE: [flexcoders] Cairngorm ServiceLocator and FDS Dimitrios Gianninas
