Thanks Dimitrios,
I like the more direct approach, but I don't
think that this would be the most effective way to handle asynchronous
events. What I'm considering is extending the Responder
all the way back to the View, through the FrontController.
They are, after all, where the CairngormEvent originated and was sent
first. The FrontController has a reference to the Command, so
it could accept a responder. The Responder to the view would
have to be created.
Pros:
The permanent stop at the Command from a
Delegate wouldn't be removed, but rather used to condition the response back to
the view. Everything else works the same in the
Command. All re-usable data is dropped-off at the
ModelLocator. The command then conditions a response that
includes the state of the call result. Things like size,
number of Objects, format, or anything that the developer wanted to know, would
be added to the Responder and sent on its way. Rather, the
event would be modified. Back at the View, local state would
be adjusted accordingly when the CairngormEvent is completed.
Cons:
A race condition may occur with the
ModelLocator binding to the view's state and the local update of state from the
View itself. Also, a reference to the original CairngormEvent
would need to be maintained by the View and the FrontController.
This would possibly add weight. Less than the Command,
Delegate, and Service, but weight just the same. Would also add script to
all views that care about a response.
I think that this approach has a more
standardized feel. Does this sound like a viable idea, that doesn't stray
significantly from Cairngorm?
-TH
--- In
flexcoders@yahoogroups.com, "JesterXL" <[EMAIL PROTECTED]>
wrote:
>
> Dude... do you know how many "results" we have in our
app?
>
> I agree, this'll work for small Flash projects, but not
for Enterprise Flex
> apps. You can't just start willy nilly throwing
small state vars on
> ModelLocator for things like this; it'd get out of
control, pretty quick.
> Granted, you can easily sanction it off in a new
StateVars specific class,
> but then you have to keep track of updating
those variables in your
> commands... no thanks, I'd rather have it baked
in.
>
> ----- Original Message -----
> From: "Dimitrios
Gianninas" [EMAIL PROTECTED]
> To:
flexcoders@yahoogroups.com
> Sent: Monday, July 10, 2006 11:53 PM
>
Subject: RE: [flexcoders] Re: Cairngorm Responder interface changes
>
>
>
> Good points, but I think that it can be handled in
the following fashion.
>
> The SearchView is an MXML component and
it has a property called results, so
> its declaration would look
something like this:
>
> <dg:SearchView id="theSearch"
results="{ModelLocator.results}" />
>
> So once your results
return, they will trigger the call to the setter method
> of the results
property, so in that setter, you can do those little things:
>
>
...
> public function set results( values:ArrayCollection ):void {
>
dg.dataProvider = values;
> // do other little things here
>
}
> ...
>
> That pretty much aught to solve your problem and
you don't have to write any
> extra code. I think the important thing to
remember is to create small
> components that will receive data via
binding and set themselves in a proper
> state (meaning changing values
on certain controls, etc...). That way its
> clean and reusable in some
cases.
>
> Dimitrios "Jimmy" Gianninas
> Optimal Payments
Inc.
>
> -----Original Message-----
> From:
flexcoders@yahoogroups.com on behalf of JesterXL
> Sent: Mon 7/10/2006
9:41 PM
> To: flexcoders@yahoogroups.com
> Subject: Re: [flexcoders]
Re: Cairngorm Responder interface changes
>
> ...Tim gave better
examples than I did. A lot of those small, GUI
> operations are what I'm
talking about.
>
> ----- Original Message -----
> From: "Tim
Hoff" [EMAIL PROTECTED]
> To: flexcoders@yahoogroups.com
> Sent: Monday,
July 10, 2006 8:00 PM
> Subject: [flexcoders] Re: Cairngorm Responder
interface changes
>
>
> Hi Steven,
>
> Sorry to
offer my .02, but here is a use-case:
>
> A search view component
includes a TextInput for the search string,
> a RadioButtonGroup that is
used for the search type selection, and
> two DateFields used for a search
date range. There is also a search
> button and a reset dates
button.
>
> When a search is performed, a responder returns a
service call
> result to the command. The command updates the ModelLocator
which
> automatically updates the view through binding. This works
great
> for the heavy lifting (data, view states..). But, what about
the
> light lifting; If results found: (clear and setFocus to the
>
TextInput control, reset search options RadioButtons, reset the
>
DateFields for a new search), If no results found: (do not reset
> fields,
display a message saying "no results found for the search,"
> prompt the
user for additional information, launch the sound of
> laughing.mpg).
:)
>
> Sure, in one way or another, all of this can be accomplished
with
> binding to variables in the ModelLocator, Alerts and PopUps.
But,
> inho, binding state for the small things, that are soley related
to
> a local view and conditional on the result of the call, serves
to
> clutter-up the ModelLocator. The view could handle some of its
own
> state if it was notified of the status of the service call. I
know
> that this is purely preferential, but why use the ModelLocator
to
> control every single state in the application, when a local
view
> could handle the small stuff? By reducing the number of
state
> variables, the views would also be easier to reuse; if,
for
> instance, you wanted to encapsulate the view by passing-in
the
> bindings to the ModelLocator in the components outer
definition.
>
> Proposal: Round-trip notification - success,
failure, or custom
> message returned to the originator of the
CairngormEvent (sans data).
>
> Possible method: Add a
ViewResponder class that passes messages
> between the Command and the
View; based on the result returned by
> the service Responder. Or, how
about attaching the Responder to the
> CairngormEvent to create a
front-to-back, full-duplex pipeline for
> the call.
>
> If
I'm totally off-base with this, please disregard.
>
> Humble
regards,
> Tim Hoff
>
> --- In flexcoders@yahoogroups.com,
"Steven Webster" swebster@
> wrote:
> >
> >
jesse,
> >
> > sorry if you've covered this already; but what
do you mean by
> commands
> > supporting callbacks, in terms of
an example usage of where you'd
> do
> > this ? can we rewind to
the use-case, so I can make sure I
> understand
> > what you're
trying to achieve here ?
> >
> > best,
> >
>
> Steven
> >
> > Steven Webster
> > Practice
Director (Rich Internet Applications)
> > Adobe Consulting
> >
Westpoint, 4 Redheughs Rigg, South Gyle, Edinburgh, EH12 9DQ, UK
> > p:
+44 (0) 131 338 6108
> > m: +44 (0) 7917 428 947
> >
swebster@
> >
> >
> >
> >
> >
________________________________
> >
> > From:
flexcoders@yahoogroups.com
> > [mailto:[EMAIL PROTECTED] On
Behalf Of JesterXL
> > Sent: 06 July 2006 21:11
> > To:
flexcoders@yahoogroups.com
> > Subject: Re: [flexcoders] Re: Cairngorm
Responder interface
> > changes
> >
> >
>
>
> > ...or you can have Commands support callbacks, and thus
no
> need
> > for state
> > variables, nor a need for
your Commands to update those
> > variables.
> >
> >
----- Original Message -----
> > From: "Steven Webster"
swebster@
> > <mailto:swebster%40adobe.com> >
> > To:
flexcoders@yahoogroups.com
> >
<mailto:flexcoders%40yahoogroups.com> >
> > Sent: Thursday,
July 06, 2006 3:57 PM
> > Subject: RE: [flexcoders] Re: Cairngorm
Responder interface
> > changes
> >
> > Agreed.
Developers *have* to take responsibility for creating
> >
application-specific classes. If your application has "10
> > million
state
> > variables", then having a StateMachine / StateManager
seems
> like
> > a
> > logical refactoring to aim for.
If however, your application
> has
> > "a
> > decent
number of states", no reason they can't be held in a
> > single
State
> > class kept on the model (our typical solution), and if
you
> only
> > have 2
> > or 3 states, even the State
class can be overkill.
> >
> > Just my $.02
>
>
> > Steven
> >
> > Steven Webster
> >
Practice Director (Rich Internet Applications)
> > Adobe
Consulting
> > Westpoint, 4 Redheughs Rigg, South Gyle, Edinburgh,
EH12
> 9DQ, UK
> > p: +44 (0) 131 338 6108
> > m: +44
(0) 7917 428 947
> > swebster@
<mailto:swebster%40adobe.com>
> >
> > > -----Original
Message-----
> > > From: flexcoders@yahoogroups.com
> >
<mailto:flexcoders%40yahoogroups.com>
> > >
[mailto:flexcoders@yahoogroups.com
> >
<mailto:flexcoders%40yahoogroups.com> ] On Behalf Of Tom Chiverton
>
> > Sent: 06 July 2006 16:01
> > > To:
flexcoders@yahoogroups.com
> >
<mailto:flexcoders%40yahoogroups.com>
> > > Subject: Re:
[flexcoders] Re: Cairngorm Responder interface
> > changes
> >
>
> > > On Thursday 06 July 2006 14:49, JesterXL wrote:
>
> > > Just what I need, 10 billion more state variables to keep
>
> > track of...
> > >
> > > Point taken, but they
don't all have to be flat i.e. direct
> > > properties of the
model.
> > > You can have model.viewHelpers.* ,
model.thingsAboutFoo.*
> etc.
> > >
> > >
--
> > > Tom Chiverton
> > >
> > >
****************************************************
> > >
>
> > This email is sent for and on behalf of Halliwells LLP.
> >
>
> > > Halliwells LLP is a limited liability partnership
>
registered
> > > in England and Wales under registered number
OC307980 whose
> > > registered office address is at St James's
Court Brown
> Street
> > > Manchester M2 2JF. A list of
members is available for
> > > inspection at the registered office.
Any reference to a
> > > partner in relation to Halliwells LLP means
a member of
> > > Halliwells LLP. Regulated by the Law
Society.
> > >
> > > CONFIDENTIALITY
> >
>
> > > This email is intended only for the use of the
addressee
> > > named above and may be confidential or legally
privileged.
> > > If you are not the addressee you must not read it
and must
> > > not use any information contained in nor copy it nor
inform
> > > any person other than Halliwells LLP or the addressee
of
> its
> > > existence or contents. If you have received
this email in
> > > error please delete it and notify Halliwells LLP
IT
> > > Department on 0870 365 8008.
> > >
> >
> For more information about Halliwells LLP visit
> >
www.halliwells.com.
> > >
> > >
> >
>
> > > ------------------------ Yahoo! Groups Sponsor
>
> > --------------------~--> See what's inside the new Yahoo!
>
> > Groups email.
> > >
http://us.click.yahoo.com/2pRQfA/bOaOAA/yQLSAA/nhFolB/TM
> >
<http://us.click.yahoo.com/2pRQfA/bOaOAA/yQLSAA/nhFolB/TM>
> >
> ----------------------------------------------------------
> >
> ------~->
> > >
> > > --
> > >
Flexcoders Mailing List
> > > FAQ:
> >
http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
> >
<http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt>
>
> > Search Archives:
> > >
http://www.mail-archive.com/flexcoders%40yahoogroups.com
> >
<http://www.mail-archive.com/flexcoders%40yahoogroups.com>
> >
> Yahoo! Groups Links
> > >
> > >
> >
>
> > >
> > >
> > >
> >
>
> >
> > --
> > Flexcoders Mailing List
>
> FAQ:
> >
http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
> >
<http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt>
>
> Search Archives:
> >
http://www.mail-archive.com/flexcoders%40yahoogroups.com
> >
<http://www.mail-archive.com/flexcoders%40yahoogroups.com>
> >
Yahoo! Groups Links
> >
>
>
>
>
>
>
>
> --
> 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
>
>
>
>
>
>
> --
> WARNING
> -------
> This electronic message and
its attachments may contain confidential,
> proprietary or legally
privileged information, which is solely for the use
> of the intended
recipient. No privilege or other rights are waived by any
> unintended
transmission or unauthorized retransmission of this message. If
> you are
not the intended recipient of this message, or if you have received
> it
in error, you should immediately stop reading this message and delete it
> and all attachments from your system. The reading, distribution,
copying or
> other use of this message or its attachments by unintended
recipients is
> unauthorized and may be unlawful. If you have received
this e-mail in
> error, please notify the sender.
>
> AVIS
IMPORTANT
> --------------
> Ce message électronique et ses pièces
jointes peuvent contenir des
> renseignements confidentiels, exclusifs ou
légalement privilégiés destinés
> au seul usage du destinataire visé.
L'expéditeur original ne renonce à
> aucun privilège ou à aucun autre
droit si le présent message a été transmis
> involontairement ou s'il est
retransmis sans son autorisation. Si vous
> n'êtes pas le destinataire
visé du présent message ou si vous l'avez reçu
> par erreur, veuillez
cesser immédiatement de le lire et le supprimer, ainsi
> que toutes ses
pièces jointes, de votre système. La lecture, la
> distribution, la copie
ou tout autre usage du présent message ou de ses
> pièces jointes par des
personnes autres que le destinataire visé ne sont pas
> autorisés et
pourraient être illégaux. Si vous avez reçu ce courrier
> électronique
par erreur, veuillez en aviser l'expéditeur.
>
>
>
>
> --
> 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
>
