Oh, please don't get me wrong, you're solution is great. It really
got me
thinking in a different direction. I'm just trying to come
up with a
standardized way to solve this need, that will generically
work for the
majority of use-cases. I don't think that the
Cairngorm guys would consider
any change unless it feels concrete
and scales easily. I sincerely
appreciate your feedback Dimitrios.
Please know that there is no disrespect
intended.
Tim Hoff
--- In [EMAIL PROTECTED]ups.com,
"Dimitrios Gianninas"
<dimitrios.giannina[EMAIL PROTECTED]>
wrote:
>
> Ok, obviously I haven't built big enough apps yet to run
into the
problems you and Jesse have. I've had to do something like that in
one app actually where I had multiple instances of the same window
created, I would send a ref of the view to the command so it would
know
which window instance to update afterwards.
>
> Dimitrios
Gianninas
> RIA Developer
> Optimal Payments Inc.
>
>
> ________________________________
>
> From:
[EMAIL PROTECTED]ups.com
[mailto:[EMAIL PROTECTED]ups.com]
On Behalf Of Tim Hoff
> Sent: Tuesday, July 11, 2006 2:06 AM
> To:
[EMAIL PROTECTED]ups.com
>
Subject: [flexcoders] Re: Cairngorm Responder interface changes
>
>
>
> 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 [EMAIL PROTECTED]ups.com,
"JesterXL" <jesterxl@> 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" dimitrios.gianninas@
> >
To: [EMAIL PROTECTED]ups.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: [EMAIL PROTECTED]ups.com
on behalf of JesterXL
> > Sent: Mon 7/10/2006 9:41 PM
> > To:
[EMAIL PROTECTED]ups.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" TimHoff@
> > To: [EMAIL PROTECTED]ups.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 [EMAIL PROTECTED]ups.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: [EMAIL PROTECTED]ups.com
>
> > [mailto:[EMAIL PROTECTED]ups.com]
On Behalf Of JesterXL
> > > Sent: 06 July 2006 21:11
> >
> To: [EMAIL PROTECTED]ups.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: [EMAIL PROTECTED]ups.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: [EMAIL PROTECTED]ups.com
>
> > <mailto:flexcoders%40yahoogroups.com>
> >
> > [mailto:[EMAIL PROTECTED]ups.com
>
> > <mailto:flexcoders%40yahoogroups.com> ] On Behalf Of
Tom
Chiverton
> > > > Sent: 06 July 2006 16:01
> >
> > To: [EMAIL PROTECTED]ups.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
> >
>
