Guys,
If I'm strangely quiet on this, it's because I plan on
blogging some thoughts rather than piece-meal response to emails here. For
what it's worth, I think there is "no right answer", this will ultimately come
down not to best-practice, but personal preference. There are some things
that strike me as "bad code smells", and I'll call 'em out if I see
them.
However, the only thought I'll throw in again - being agile
boy again - is that I'd err on the simplest solution that works, and introduce
complexity (and ultimately refactor the framework itself) only once I'm actually
in there suffering the pain of the problem, not having foresight of the problem
as he sees it. Jimmy G is being modest when he says he hasn't built big
apps ... he's been building some pretty typical RIA with Flex for quite some
time, if what he showed me in New Orleans at MAX2004 is anything to go
by.
I think we have to be careful when we start making changes
to Cairngorm, and at least ask ourselves the question "is this useful to me, or
useful to all applications built upon Cairngorm". The former, or somewhere
in-between is the norm, the latter is the only time I would be comfortable
changing (rather than extending the classes of) the framework. Bear in
mind as soon as you work from your own modified Cairngorm classes, you're going
to find it difficult to migrate with us.
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
| |
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 > > >
__._,_.___
--
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
__,_._,___
|