[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 approachhas 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 changesGood 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,
Re: [flexcoders] Re: Cairngorm Responder interface changes
On Tuesday 11 July 2006 01:00, Tim Hoff wrote: 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 agree, totally. I'd really like some way, maybe as an extra optional arg on the CairngormEventDispatcher, to say 'this view[helper] has the onResult method to call'. Maybe then another for the fault handler. If either is empty, Cairngorm looks in the same places as now. -- 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. -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
RE: [flexcoders] Re: Cairngorm Responder interface changes
Ok, obviously I haven't built big enough apps yet to run
into the problemsyou 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 refof the view to the command so it would know which window
instance to update afterwards.
Dimitrios
Gianninas
RIADeveloper
Optimal
Payments Inc.
From: flexcoders@yahoogroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of Tim HoffSent:
Tuesday, July 11, 2006 2:06 AMTo:
flexcoders@yahoogroups.comSubject: [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 approachhas 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 ModelLoc
Re: [flexcoders] Re: Cairngorm Responder interface changes
On Tuesday 11 July 2006 13:25, Dimitrios Gianninas wrote: 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. Were finding we have to do that quite a lot, and it seems like we're working around a feature rather than with the framework. -- 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. -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
[flexcoders] Re: Cairngorm Responder interface changes
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 flexcoders@yahoogroups.com, Dimitrios Gianninas
[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: flexcoders@yahoogroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of Tim Hoff
Sent: Tuesday, July 11, 2006 2:06 AM
To: flexcoders@yahoogroups.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 flexcoders@yahoogroups.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: 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
Re: [flexcoders] Re: Cairngorm Responder interface changes
I didn't effectively communicate that, but tried to in my email. Creating a seperate class for those states is nice because it can still reside in your model package. However, managing those variables in commands and setting them seems like a lot of overhead to manage. The View's are the ones who care about the state, not the overall app, and thus they should be the ones responsible for responding. If it's a result handler, it's built into the framework, and View's can choose to respond. I'm sure there are scenarios where doing this way is ok too. - Original Message - From: Ralf Bokelberg [EMAIL PROTECTED] To: flexcoders@yahoogroups.com Sent: Tuesday, July 11, 2006 1:54 AM Subject: Re: [flexcoders] Re: Cairngorm Responder interface changes How about creating a new class SearchResults with all the different bindable state variables in it? This way you don't loose the advantage of pure mvc without the clutter. Cheers, Ralf. On 7/11/06, JesterXL [EMAIL PROTECTED] wrote: Dude... do you know how many results we have in our app? -- 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 Yahoo! Groups Sponsor ~-- Great things are happening at Yahoo! Groups. See the new email design. http://us.click.yahoo.com/TISQkA/hOaOAA/yQLSAA/nhFolB/TM ~- -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
RE: [flexcoders] Re: Cairngorm Responder interface changes
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 WebsterPractice Director (Rich
Internet Applications)Adobe ConsultingWestpoint, 4 Redheughs
Rigg, South Gyle, Edinburgh, EH12 9DQ, UKp: +44 (0) 131 338
6108
m: +44 (0)7917 428 947[EMAIL PROTECTED]
From: flexcoders@yahoogroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of Tim
HoffSent: 11 July 2006 14:35To:
flexcoders@yahoogroups.comSubject: [flexcoders] Re: Cairngorm
Responder interface changes
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 PROTECTE
RE: [flexcoders] Re: Cairngorm Responder interface changes
None taken :)
Throwing around ideas will eventually lead to the proper
solution.
Dimitrios
Gianninas
RIADeveloper
Optimal
Payments Inc.
From: flexcoders@yahoogroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of Tim HoffSent:
Tuesday, July 11, 2006 9:35 AMTo:
flexcoders@yahoogroups.comSubject: [flexcoders] Re: Cairngorm
Responder interface changes
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
[flexcoders] Re: Cairngorm Responder interface changes
Great, The migration issue is exactly why I don't wan't to have to hack this. My thoughts are for the development community at large. As a developer, the time that is required to devise or learn someone else's hack is much better served adding features. In looking at the framework, it's outstanding in every area. I believe that adding an event bridge back to the view will add to Cairngorm's flexibility. The beauty is, that if that you don't want to use the bridge, you don't have to. Developers can continue to maintain Local State and Shared State in the ModelLocator if desired. No worries. Or, they can choose to clean-up the ModelLocator by eliminating Local State variables altogether. This seems simple enough, without making radical changes to the framework. There are also several other proposed changes on this thread, that many agree should merit consideration. If these issues were just MY foresight or opinions, I would not have continued. But when several credible sources agree that something could be better, there's nothing wrong with a little proactivity. I'm so happy that people are sharing their passion for Flex and Cairngorm here. By participating, this forum is giving all of us the opportunity to jump ahead of the curve. Jesse, or anyone, if you have anything to add, please chime-in. This is my last bid for this issue. Steven, I'm sure, as always, that you will thoughtfully take everything discussed into consideration. I look forward to your blog opinions. Best Wishes, Tim Hoff --- In flexcoders@yahoogroups.com, Steven Webster [EMAIL PROTECTED] wrote: 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 m: +44 (0) 7917 428 947 [EMAIL PROTECTED] From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Tim Hoff Sent: 11 July 2006 14:35 To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Cairngorm Responder interface changes 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 flexcoders@yahoogroups.com mailto:flexcoders% 40yahoogroups.com , Dimitrios Gianninas dimitrios.gianninas@ 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: flexcoders@yahoogroups.com mailto:flexcoders% 40yahoogroups.com [mailto:flexcoders@yahoogroups.com mailto:flexcoders% 40yahoogroups.com ] On Behalf Of Tim Hoff Sent: Tuesday, July 11, 2006 2:06 AM
Re: [flexcoders] Re: Cairngorm Responder interface changes
I just have to say I don't want Steven or Aral's job. Making maintaing frameworks is f'ing hard, and I'm glad I get the luxury of proposing ideas without too much thought given to the potential consequences to the greater developer community whereas he does. The fact that he is passionate about ensuring success, and yet open to ideas is pimp! - Original Message - From: Tim Hoff [EMAIL PROTECTED] To: flexcoders@yahoogroups.com Sent: Tuesday, July 11, 2006 1:12 PM Subject: [flexcoders] Re: Cairngorm Responder interface changes Great, The migration issue is exactly why I don't wan't to have to hack this. My thoughts are for the development community at large. As a developer, the time that is required to devise or learn someone else's hack is much better served adding features. In looking at the framework, it's outstanding in every area. I believe that adding an event bridge back to the view will add to Cairngorm's flexibility. The beauty is, that if that you don't want to use the bridge, you don't have to. Developers can continue to maintain Local State and Shared State in the ModelLocator if desired. No worries. Or, they can choose to clean-up the ModelLocator by eliminating Local State variables altogether. This seems simple enough, without making radical changes to the framework. There are also several other proposed changes on this thread, that many agree should merit consideration. If these issues were just MY foresight or opinions, I would not have continued. But when several credible sources agree that something could be better, there's nothing wrong with a little proactivity. I'm so happy that people are sharing their passion for Flex and Cairngorm here. By participating, this forum is giving all of us the opportunity to jump ahead of the curve. Jesse, or anyone, if you have anything to add, please chime-in. This is my last bid for this issue. Steven, I'm sure, as always, that you will thoughtfully take everything discussed into consideration. I look forward to your blog opinions. Best Wishes, Tim Hoff --- In flexcoders@yahoogroups.com, Steven Webster [EMAIL PROTECTED] wrote: 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 m: +44 (0) 7917 428 947 [EMAIL PROTECTED] From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Tim Hoff Sent: 11 July 2006 14:35 To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Cairngorm Responder interface changes 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 flexcoders@yahoogroups.com mailto:flexcoders% 40yahoogroups.com , Dimitrios Gianninas dimitrios.gianninas@ 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
Re: [flexcoders] Re: Cairngorm Responder interface changes
Yeah, keeping it simple, in a way that almost hurts, is the hardest thing to do. Cheers, Ralf. On 7/11/06, JesterXL [EMAIL PROTECTED] wrote: I just have to say I don't want Steven or Aral's job. Making maintaing frameworks is f'ing hard, and I'm glad I get the luxury of proposing ideas without too much thought given to the potential consequences to the greater developer community whereas he does. The fact that he is passionate about ensuring success, and yet open to ideas is pimp! Yahoo! Groups Sponsor ~-- Great things are happening at Yahoo! Groups. See the new email design. http://us.click.yahoo.com/TISQkA/hOaOAA/yQLSAA/nhFolB/TM ~- -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
RE: [flexcoders] Re: Cairngorm Responder interface changes
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 WebsterPractice Director (Rich Internet Applications)Adobe ConsultingWestpoint, 4 Redheughs Rigg, South Gyle, Edinburgh, EH12 9DQ, UKp: +44 (0) 131 338 6108 m: +44 (0)7917 428 947[EMAIL PROTECTED] From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of JesterXLSent: 06 July 2006 21:11To: flexcoders@yahoogroups.comSubject: 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" [EMAIL PROTECTED]comTo: [EMAIL PROTECTED]ups.comSent: Thursday, July 06, 2006 3:57 PMSubject: RE: [flexcoders] Re: Cairngorm Responder interface changesAgreed. Developers *have* to take responsibility for creatingapplication-specific classes. If your application has "10 million statevariables", then having a StateMachine / StateManager seems like alogical refactoring to aim for. If however, your application has "adecent number of states", no reason they can't be held in a single Stateclass kept on the model (our typical solution), and if you only have 2or 3 states, even the State class can be overkill.Just my $.02StevenSteven WebsterPractice Director (Rich Internet Applications)Adobe ConsultingWestpoint, 4 Redheughs Rigg, South Gyle, Edinburgh, EH12 9DQ, UKp: +44 (0) 131 338 6108m: +44 (0) 7917 428 947[EMAIL PROTECTED]com -Original Message- From: [EMAIL PROTECTED]ups.com [mailto:[EMAIL PROTECTED]ups.com] On Behalf Of Tom Chiverton Sent: 06 July 2006 16:01 To: [EMAIL PROTECTED]ups.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 -- --~- -- 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 ListFAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txtSearch Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! 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 Web site design development Computer software development Software design and development Macromedia flex Software development best practice YAHOO! GROUPS LINKS Visit your group "flexcoders" on the web
[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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED]
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
[EMAIL PROTECTED]
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 [EMAIL PROTECTED]
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
Re: [flexcoders] Re: Cairngorm Responder interface changes
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 [EMAIL PROTECTED]
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
[EMAIL PROTECTED]
From: flexcoders@yahoogroups.com
[mailto:[EMAIL PROTECTED
Re: [flexcoders] Re: Cairngorm Responder interface changes
How about creating a new class SearchResults with all the different bindable state variables in it? This way you don't loose the advantage of pure mvc without the clutter. Cheers, Ralf. On 7/11/06, JesterXL [EMAIL PROTECTED] wrote: Dude... do you know how many results we have in our app? Yahoo! Groups Sponsor ~-- Check out the new improvements in Yahoo! Groups email. http://us.click.yahoo.com/6pRQfA/fOaOAA/yQLSAA/nhFolB/TM ~- -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [flexcoders] Re: Cairngorm Responder interface changes
On Tuesday 04 July 2006 15:28, JesterXL wrote:
2. Command callbacks. Sometimes, there is a legitimate need for a View to
know when a Command is completed. In my consulting, we've added an
In which case it should use data binding, and the event result updates
something in the model.
Remember you can bind to data via a function:
selectedIndex={findOutIndexForMyViewFromModelState(model)}
--
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 ~--
Great things are happening at Yahoo! Groups. See the new email design.
http://us.click.yahoo.com/TISQkA/hOaOAA/yQLSAA/nhFolB/TM
~-
--
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
* To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/
* To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
* Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Re: [flexcoders] Re: Cairngorm Responder interface changes
Just what I need, 10 billion more state variables to keep track of...
- Original Message -
From: Tom Chiverton [EMAIL PROTECTED]
To: flexcoders@yahoogroups.com
Sent: Thursday, July 06, 2006 5:41 AM
Subject: Re: [flexcoders] Re: Cairngorm Responder interface changes
On Tuesday 04 July 2006 15:28, JesterXL wrote:
2. Command callbacks. Sometimes, there is a legitimate need for a View to
know when a Command is completed. In my consulting, we've added an
In which case it should use data binding, and the event result updates
something in the model.
Remember you can bind to data via a function:
selectedIndex={findOutIndexForMyViewFromModelState(model)}
--
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.
--
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
Yahoo! Groups Sponsor ~--
Something is new at Yahoo! Groups. Check out the enhanced email design.
http://us.click.yahoo.com/SISQkA/gOaOAA/yQLSAA/nhFolB/TM
~-
--
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
* To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/
* To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
* Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
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 ~- -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
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 [EMAIL PROTECTED] -Original Message- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Tom Chiverton Sent: 06 July 2006 16:01 To: flexcoders@yahoogroups.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 -- --~- -- 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 Yahoo! Groups Sponsor ~-- Great things are happening at Yahoo! Groups. See the new email design. http://us.click.yahoo.com/TISQkA/hOaOAA/yQLSAA/nhFolB/TM ~- -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
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 [EMAIL PROTECTED] To: flexcoders@yahoogroups.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 [EMAIL PROTECTED] -Original Message- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Tom Chiverton Sent: 06 July 2006 16:01 To: flexcoders@yahoogroups.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 -- --~- -- 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 Yahoo! Groups Links Yahoo! Groups Sponsor ~-- Yahoo! Groups gets a make over. See the new email design. http://us.click.yahoo.com/XISQkA/lOaOAA/yQLSAA/nhFolB/TM ~- -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
[flexcoders] Re: Cairngorm Responder interface changes
I'd appreciate the callback approach, so that you could choose to update bound state on the model or update control settings locally. That seems like a logical balance. Inho (.015), not all state needs to be controled by the model. If I wanted to clear a TextInput field or reset a RadioButtonGroup, based on the result of a command call, currently I'd have to clutter-up the ModelLocator with redundant state variables for these controls. When, in fact, the state of these individual controls is irrelevant to the state of the application. Yes, if the state of individual controls is needed in other parts of the application, it would be necessary to maintain state variables. But, if the controls are isolated inside a view component, they can be more efficiently controled within the component itself. Wish list: eventListener (responder) back to the gesture origin. -TH --- In flexcoders@yahoogroups.com, JesterXL [EMAIL PROTECTED] wrote: ...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 [EMAIL PROTECTED] To: flexcoders@yahoogroups.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 [EMAIL PROTECTED] -Original Message- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Tom Chiverton Sent: 06 July 2006 16:01 To: flexcoders@yahoogroups.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 -- --~- -- 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 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
[flexcoders] Re: Cairngorm Responder interface changes
Hi Jesse, Let me start by saying that I acquiesce; no more viewHelpers. All code has been rolled into the view. For component oriented development, it makes sense. Concerning your cogent points of view: 1) ResultEvent FaultEvent events: Not sure how much of an impact this makes in reality, But yes, do we need to support undefined? It adds weight. 2) Command callbacks: When I first got into Cairngorm, I wondered why there wasn't a round trip of communication back to the view/gesture. There are plenty of local view actions that benefit from knowing the result of a command; maybe ViewResponder. Here, I would hope that you would accept Steven's invitation to show your enhanced code, so that it might benefit all of us by possibly being rolled into Cairngorm. Functions vs. state variables: Yes, the scope of the function dictates the need for state representation. I mean, if model == state, should every toggled RadioButton or focused TextInput require a state variable for control. At a point it becomes redundant, and more efficient to address locally. 3) Added 2 methods to ServiceLocator: See #2 about sharing and possible adoption. My comments to you are not personal, or even professional. I have seen your work, website, and sat in on one of your online presentations. I think that you are brilliant. Being from SoCal, I know and appreciate your snowboarder mentality. :) I agree with your points here. I would just hope that, instead of bagging, you would contribute your proposed solutions, so that we all might enjoy a cleaner architecture. ::looking for teddy bears:: -TH --- In flexcoders@yahoogroups.com, JesterXL [EMAIL PROTECTED] wrote: Sending again; sent at like 10:00am this morning, but still don't see it. 10:03pm now. - 1. ResultEvent FaultEvent events. I disagree with this change, so have changed them back instead of of using the * change for the Responder interface. 2. Command callbacks. Sometimes, there is a legitimate need for a View to know when a Command is completed. In my consulting, we've added an optional callback method that can be passed via EventBroadcaster (Cairngorm 1). So, View's launching Commands have the option of using a Callback (like flash.net.Responder) to have a result method called when the Command is done. We extended Cairngorm's command to have all of this plumbing hidden. The convention we have is, If the View has his onResult run, he can conclude that the Command succeeded in it's operation. If a fault was fired in the Delegate, this means the app is broken and needs to be fixed. There is no error handling, only error fixing. In my personal work, I've implemented both; result and faults, via Event's. If an event extends my JXLEvent class (which extends Cairngorm), it has the option of getting those callbacks. I should probably do it like we do it at work, but for now, it works. I like handling errors, so although fault and result are pretty low level, I can have View's handle errors (or Commands obviously). Both avoid ViewLocator via a nice convention. It also makes it cake to have a chained command with visual feedback. You can have your View fire off other commands in a particular order AND show visual feedback the whole time. Could you do this by binding? Sure, but I'd rather use functions vs. state variables. 3. Added 2 methods to ServiceLocator. He doesn't support Producer or Consumer (MessageAgent) services, so with a new method he does. He also doesn't support NetConnection; with the new method, he does. Since Cairngorm was made for a more request response, it feels like both of the above are halfway implemented, but for sending messages, Cairngorm works great, including Acknowledge messages for Delegates that fire the original message. In both cases, actual callbacks are handled by totally different classes that basically act as Observers, and emit events. The more specialized (for example, a channel in FDS created for Text messages, and thus Chat only) is an extension of that ConsumerObserver class, called ChatObsever, and he omits Chat specific events for those who care. They, like Delegate's, utlize ServiceLocator. I would, however, prefer you all either give me a better idea(s), christen this idea as good for handling NetConnection / FDS' consumer/producer model, and/or implement something that supports these push based technologies into Cairngorm. With the exclusion of #1, both #2, and #3 can be done via extneding the Cairngorm base classes so you're not affecting the original framework, only extending it. I'd prefer #3 be made official though, by you all somehow, some way. - Original Message - From: Steven Webster To: flexcoders@yahoogroups.com Sent: Monday, July 03, 2006 6:03 PM Subject: RE: [flexcoders] Re: Cairngorm Responder interface changes Jesse, I'd love for you to share
Re: [flexcoders] Re: Cairngorm Responder interface changes
Tim, as long as you don't go off and use AJAX, we'll all love you no matter what you do. 1. Nope. The common use case is remoting calls, webservices 2nd, httpservices 3rd. Everyeone will get ResultEvents FaultEvents. Those who don't are using custom stuff, and thus know what they are getting into. 2. Steven, and others like my boss the architect, do not like the possibility of View's getting raw server data. For example, an unfettered / un-processed result that comes back from a Delegate call could make it's way back to the View the originaly fired the Command. This makes it all too easy for developers not experienced with Cairngorm to allow View's to start screwing with data. They also have to know about ResultEvents and FaultEvents. To me, it's worth it; we just use the convention if we get a result, it succeeded and follow the original rules. Regarding state, yeah man, you stated my feelings exactly. 3. Cool. I'm working on training online material, professional for a change, that will have a lot of the above. The rest I'll blog as usual when it's presentable. - Original Message - From: Tim Hoff [EMAIL PROTECTED] To: flexcoders@yahoogroups.com Sent: Wednesday, July 05, 2006 2:51 AM Subject: [flexcoders] Re: Cairngorm Responder interface changes Hi Jesse, Let me start by saying that I acquiesce; no more viewHelpers. All code has been rolled into the view. For component oriented development, it makes sense. Concerning your cogent points of view: 1) ResultEvent FaultEvent events: Not sure how much of an impact this makes in reality, But yes, do we need to support undefined? It adds weight. 2) Command callbacks: When I first got into Cairngorm, I wondered why there wasn't a round trip of communication back to the view/gesture. There are plenty of local view actions that benefit from knowing the result of a command; maybe ViewResponder. Here, I would hope that you would accept Steven's invitation to show your enhanced code, so that it might benefit all of us by possibly being rolled into Cairngorm. Functions vs. state variables: Yes, the scope of the function dictates the need for state representation. I mean, if model == state, should every toggled RadioButton or focused TextInput require a state variable for control. At a point it becomes redundant, and more efficient to address locally. 3) Added 2 methods to ServiceLocator: See #2 about sharing and possible adoption. My comments to you are not personal, or even professional. I have seen your work, website, and sat in on one of your online presentations. I think that you are brilliant. Being from SoCal, I know and appreciate your snowboarder mentality. :) I agree with your points here. I would just hope that, instead of bagging, you would contribute your proposed solutions, so that we all might enjoy a cleaner architecture. ::looking for teddy bears:: -TH --- In flexcoders@yahoogroups.com, JesterXL [EMAIL PROTECTED] wrote: Sending again; sent at like 10:00am this morning, but still don't see it. 10:03pm now. - 1. ResultEvent FaultEvent events. I disagree with this change, so have changed them back instead of of using the * change for the Responder interface. 2. Command callbacks. Sometimes, there is a legitimate need for a View to know when a Command is completed. In my consulting, we've added an optional callback method that can be passed via EventBroadcaster (Cairngorm 1). So, View's launching Commands have the option of using a Callback (like flash.net.Responder) to have a result method called when the Command is done. We extended Cairngorm's command to have all of this plumbing hidden. The convention we have is, If the View has his onResult run, he can conclude that the Command succeeded in it's operation. If a fault was fired in the Delegate, this means the app is broken and needs to be fixed. There is no error handling, only error fixing. In my personal work, I've implemented both; result and faults, via Event's. If an event extends my JXLEvent class (which extends Cairngorm), it has the option of getting those callbacks. I should probably do it like we do it at work, but for now, it works. I like handling errors, so although fault and result are pretty low level, I can have View's handle errors (or Commands obviously). Both avoid ViewLocator via a nice convention. It also makes it cake to have a chained command with visual feedback. You can have your View fire off other commands in a particular order AND show visual feedback the whole time. Could you do this by binding? Sure, but I'd rather use functions vs. state variables. 3. Added 2 methods to ServiceLocator. He doesn't support Producer or Consumer (MessageAgent) services, so with a new method he does. He also doesn't support NetConnection; with the new method, he does. Since Cairngorm was made for a more request response, it feels like both of the above are halfway implemented
[flexcoders] Re: Cairngorm Responder interface changes
Cool, thanks man. Yeah, concerning the callbacks (2), just intrested to know success or failure (no data), so the view could react if necessary (applicable when binding is overkill, of course). -TH --- In flexcoders@yahoogroups.com, JesterXL [EMAIL PROTECTED] wrote: Tim, as long as you don't go off and use AJAX, we'll all love you no matter what you do. 1. Nope. The common use case is remoting calls, webservices 2nd, httpservices 3rd. Everyeone will get ResultEvents FaultEvents. Those who don't are using custom stuff, and thus know what they are getting into. 2. Steven, and others like my boss the architect, do not like the possibility of View's getting raw server data. For example, an unfettered / un-processed result that comes back from a Delegate call could make it's way back to the View the originaly fired the Command. This makes it all too easy for developers not experienced with Cairngorm to allow View's to start screwing with data. They also have to know about ResultEvents and FaultEvents. To me, it's worth it; we just use the convention if we get a result, it succeeded and follow the original rules. Regarding state, yeah man, you stated my feelings exactly. 3. Cool. I'm working on training online material, professional for a change, that will have a lot of the above. The rest I'll blog as usual when it's presentable. - Original Message - From: Tim Hoff [EMAIL PROTECTED] To: flexcoders@yahoogroups.com Sent: Wednesday, July 05, 2006 2:51 AM Subject: [flexcoders] Re: Cairngorm Responder interface changes Hi Jesse, Let me start by saying that I acquiesce; no more viewHelpers. All code has been rolled into the view. For component oriented development, it makes sense. Concerning your cogent points of view: 1) ResultEvent FaultEvent events: Not sure how much of an impact this makes in reality, But yes, do we need to support undefined? It adds weight. 2) Command callbacks: When I first got into Cairngorm, I wondered why there wasn't a round trip of communication back to the view/gesture. There are plenty of local view actions that benefit from knowing the result of a command; maybe ViewResponder. Here, I would hope that you would accept Steven's invitation to show your enhanced code, so that it might benefit all of us by possibly being rolled into Cairngorm. Functions vs. state variables: Yes, the scope of the function dictates the need for state representation. I mean, if model == state, should every toggled RadioButton or focused TextInput require a state variable for control. At a point it becomes redundant, and more efficient to address locally. 3) Added 2 methods to ServiceLocator: See #2 about sharing and possible adoption. My comments to you are not personal, or even professional. I have seen your work, website, and sat in on one of your online presentations. I think that you are brilliant. Being from SoCal, I know and appreciate your snowboarder mentality. :) I agree with your points here. I would just hope that, instead of bagging, you would contribute your proposed solutions, so that we all might enjoy a cleaner architecture. ::looking for teddy bears:: -TH --- In flexcoders@yahoogroups.com, JesterXL jesterxl@ wrote: Sending again; sent at like 10:00am this morning, but still don't see it. 10:03pm now. - 1. ResultEvent FaultEvent events. I disagree with this change, so have changed them back instead of of using the * change for the Responder interface. 2. Command callbacks. Sometimes, there is a legitimate need for a View to know when a Command is completed. In my consulting, we've added an optional callback method that can be passed via EventBroadcaster (Cairngorm 1). So, View's launching Commands have the option of using a Callback (like flash.net.Responder) to have a result method called when the Command is done. We extended Cairngorm's command to have all of this plumbing hidden. The convention we have is, If the View has his onResult run, he can conclude that the Command succeeded in it's operation. If a fault was fired in the Delegate, this means the app is broken and needs to be fixed. There is no error handling, only error fixing. In my personal work, I've implemented both; result and faults, via Event's. If an event extends my JXLEvent class (which extends Cairngorm), it has the option of getting those callbacks. I should probably do it like we do it at work, but for now, it works. I like handling errors, so although fault and result are pretty low level, I can have View's handle errors (or Commands obviously). Both avoid ViewLocator via a nice convention. It also makes it cake to have a chained command with visual feedback. You can have your View fire off other commands in a particular order AND show visual feedback the whole time. Could you do
Re: [flexcoders] Re: Cairngorm Responder interface changes
1. ResultEvent FaultEvent events. I
disagree with this change, so have changed them backinstead ofof
using the * changefor the Responder interface.
2. Command callbacks. Sometimes, there is a
legitimate need for a View to "know" when a Command is completed. In my
consulting, we've added an optional callback method that can be passed via
EventBroadcaster (Cairngorm 1). So, View's launching Commands have the
option of using a Callback (like flash.net.Responder) to have a result method
called when the Command is done. We extended Cairngorm's command to have
all of this plumbing hidden. The convention we have is, "If the View has
his onResult run, he can conclude that the Command succeeded in it's
operation." If a fault was fired in the Delegate, this means the app is
broken and needs to be fixed. There is no error handling, only error
fixing.
In my personal work, I've implemented both; result
and faults, via Event's. If an event extends my JXLEvent class (which
extends Cairngorm), it has the option of getting those callbacks. I should
probably do it like we do it at work, but for now, it works. I like
handling errors, so although fault and result are pretty low level, I can have
View's handle errors (or Commands obviously).
Both avoid ViewLocator via a nice convention.
It also makes it cake to have a chained command with visual feedback. You
can have your View fire off other commands in a particular order AND show visual
feedback the whole time. Could you do this by binding? Sure,
butI'd rather use functions vs. state variables.
3. Added 2 methods to ServiceLocator. He
doesn't support Producer or Consumer (MessageAgent) services, so with a new
method he does. He also doesn't support NetConnection; with the new
method, he does. Since Cairngorm was made for a more request response, it
feels like both of the above are halfway implemented, but for sending messages,
Cairngorm works great, including Acknowledge messages for Delegates that fire
the original message. In both cases, actual callbacks are handled by
totally different classes that basically act as Observers, and emit
events. The more specialized (for example, a channel in FDS created for
Text messages, and thus Chat only) is an extension of that ConsumerObserver
class, called ChatObsever, and he omits Chat specific events for those who
care. They, like Delegate's, utlize ServiceLocator.
I would, however, prefer you all either give me a
better idea(s), christen this idea as good for handling NetConnection / FDS'
consumer/producer model, and/or implement something that supports these push
based technologies into Cairngorm.
With the exclusion of #1, both #2, and #3 can be
done via extneding the Cairngorm base classes so you're not affecting the
original framework, only extending it. I'd prefer #3 be made official
though, by you all somehow, some way.
- Original Message -
From: Steven Webster
To: flexcoders@yahoogroups.com
Sent: Monday, July 03, 2006 6:03 PM
Subject: RE: [flexcoders] Re: Cairngorm Responder interface
changes
Jesse,
I'd love for you to share the modifications you're making
to Cairngorm, and to understand the rationale behind these changes. It's
not our intention that developers would typically need to change the
framework locally, and doing so certainly makes it more difficult for folks to
follow us on any upgrade paths as time rolls by. Different strokes for
different folks though.
But if you can share your motives for changes, and the
changes themselves, then we can consider rolling them into the framework if they
satisfy general concerns.
Best,
Steven
Steven WebsterPractice Director (Rich
Internet Applications)Adobe ConsultingWestpoint, 4 Redheughs
Rigg, South Gyle, Edinburgh, EH12 9DQ, UKp: +44 (0) 131 338
6108
m: +44 (0)7917 428 947[EMAIL PROTECTED]
From: flexcoders@yahoogroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of
JesterXLSent: 03 July 2006 20:13To:
flexcoders@yahoogroups.comSubject: Re: [flexcoders] Re: Cairngorm
Responder interface changes
Don't have Flex 2 open in front of me ( client hearts 1.5 ), but you can I
think do:public function onResult(event:* =
null):void{ResultEvent(event).result// or...var
yourEvent:ResultEvent = event as ResultEvent;}I can't
remember if you can cast in the function signature as:public function
onResult ( event:* as ResultEvent = null )...but, either way, you can
also do what I do; keep your own build of Cairngorm locally! I've yet to
work on a project where the team didn't modify their build of Cairngorm to
suit their needs.- Original Message - From:
"ben.clinkinbeard" ben.clinkinbeard@gmail.comTo:
[EMAIL PROTECTED]ups.comSent:
Monday, July 03, 2006 3:00 PMSubject: [flexc
RE: [flexcoders] Re: Cairngorm Responder interface changes
Jesse,
I'd love for you to share the modifications you're making
to Cairngorm, and to understand the rationale behind these changes. It's
not our intention that developers would typically need to change the
framework locally, and doing so certainly makes it more difficult for folks to
follow us on any upgrade paths as time rolls by. Different strokes for
different folks though.
But if you can share your motives for changes, and the
changes themselves, then we can consider rolling them into the framework if they
satisfy general concerns.
Best,
Steven
Steven WebsterPractice Director (Rich
Internet Applications)Adobe ConsultingWestpoint, 4 Redheughs
Rigg, South Gyle, Edinburgh, EH12 9DQ, UKp: +44 (0) 131 338
6108
m: +44 (0)7917 428 947[EMAIL PROTECTED]
From: flexcoders@yahoogroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of
JesterXLSent: 03 July 2006 20:13To:
flexcoders@yahoogroups.comSubject: Re: [flexcoders] Re: Cairngorm
Responder interface changes
Don't have Flex 2 open in front of me ( client hearts 1.5 ), but you can I
think do:public function onResult(event:* =
null):void{ResultEvent(event).result// or...var
yourEvent:ResultEvent = event as ResultEvent;}I can't
remember if you can cast in the function signature as:public function
onResult ( event:* as ResultEvent = null )...but, either way, you can
also do what I do; keep your own build of Cairngorm locally! I've yet to
work on a project where the team didn't modify their build of Cairngorm to
suit their needs.- Original Message - From:
"ben.clinkinbeard" ben.clinkinbeard@gmail.comTo:
[EMAIL PROTECTED]ups.comSent:
Monday, July 03, 2006 3:00 PMSubject: [flexcoders] Re: Cairngorm Responder
interface changesAh ha. Actually, I had to change them
topublic function onResult(event:* = null):voidpublic
function onFault(event:* = null):voidso that they matched the
signature exactly. I guess my confusion wasin that I was viewing the :* as
meaning the developer could specifywhatever type they wanted. I was seeing
* as a kind of superclass whenthat is in fact not the case. I have to
agree with Jester; I don'treally see the point of this
change.Thanks for your help,Ben--- In [EMAIL PROTECTED]ups.com,
"Clint Modien" [EMAIL PROTECTED] wrote: you need to
change these lines public function
onResult(event:ResultEvent):void public function
onFault(event:FaultEvent):void to
this... public function onResult(event:*):void
public function onFault(event:*)void On 7/3/06,
ben.clinkinbeard ben.clinkinbeard@... wrote:
Can someone explain why it is telling me I've implemented the
Responder methods with an incompatible signature?
public function onResult(event:ResultEvent):void
public function onFault(event:FaultEvent):void
The signatures shown in the docs are public
function onResult(event:* = null):void public function
onFault(event:* = null):void What am I missing
here? Thanks, Ben
--- In [EMAIL PROTECTED]ups.com
flexcoders%40yahoogroups.com, "der_kotty"
kotty.tm@ wrote: Hi,
I was just wondering why the
com.adobe.cairngorm.business.Responder interface
has been changed since it has been released on Adobe Labs.
In Cairngorm 2.0 alpha (org.nevis.cairngorm.business.Responder)
the parameters of the onFault and onResult handlers were
typed events (ResultEvent and FaultEvent).
Why have the parameters been changed to '*'? Where is
the sense in that? To my opinion this is not really best
practice but maybe there's a really good reason for that?
Does anyone know? Cheers
David
--Flexcoders Mailing ListFAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txtSearch
Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo!
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
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.
__,_._,___
RE: [flexcoders] Re: Cairngorm Responder interface changes
Hi Steven;
Although I risk being accused of hijacking
this thread, I can suggest one change to Cairngorm:
com.adobe.cairngorm.control.FrontController
private
function executeCommand( event : CairngormEvent ) : void
{
var commandToInitialise : Class = getCommand( event.type );
var commandToExecute : Command = new commandToInitialise();
event.stopPropogation(); //change is here
commandToExecute.execute( event );
}
In the case where application A
dynamically loads application B into a separate application domain that is not
a child of application As domain, the FrontController of application A
will get events from application B. Since an event from application B cannot be
coerced into the event class with the same name in application A, a run-time
error will occur unless propagation of the event is halted in application Bs
front controller.
I mention this now because Im in
the process of converting our Flex 2B3 application to Flex 2 (final) and am
copying the change in FrontController.
Tobias.
From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Steven Webster
Sent: Monday, July 03, 2006 3:03
PM
To: flexcoders@yahoogroups.com
Subject: RE: [flexcoders] Re:
Cairngorm Responder interface changes
Jesse,
I'd love for you to share the
modifications you're making to Cairngorm, and to understand the rationale
behind these changes. It's not our intention that developers would
typically need to change the framework locally, and doing so certainly makes
it more difficult for folks to follow us on any upgrade paths as time rolls
by. Different strokes for different folks though.
But if you can share your motives for
changes, and the changes themselves, then we can consider rolling them into the
framework if they satisfy general concerns.
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
[EMAIL PROTECTED]
From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of JesterXL
Sent: 03 July 2006 20:13
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] Re:
Cairngorm Responder interface changes
Don't have Flex 2 open in front of me ( client hearts
1.5 ), but you can I
think do:
public function onResult(event:* = null):void
{
ResultEvent(event).result
// or...
var yourEvent:ResultEvent = event as ResultEvent;
}
I can't remember if you can cast in the function signature as:
public function onResult ( event:* as ResultEvent = null )
...but, either way, you can also do what I do; keep your own build of
Cairngorm locally! I've yet to work on a project where the team didn't
modify their build of Cairngorm to suit their needs.
- Original Message -
From: ben.clinkinbeard ben.clinkinbeard@gmail.com
To: [EMAIL PROTECTED]ups.com
Sent: Monday, July 03, 2006 3:00 PM
Subject: [flexcoders] Re: Cairngorm Responder interface changes
Ah ha. Actually, I had to change them to
public function onResult(event:* = null):void
public function onFault(event:* = null):void
so that they matched the signature exactly. I guess my confusion was
in that I was viewing the :* as meaning the developer could specify
whatever type they wanted. I was seeing * as a kind of superclass when
that is in fact not the case. I have to agree with Jester; I don't
really see the point of this change.
Thanks for your help,
Ben
--- In [EMAIL PROTECTED]ups.com,
Clint Modien [EMAIL PROTECTED] wrote:
you need to change these lines
public function onResult(event:ResultEvent):void
public function onFault(event:FaultEvent):void
to this...
public function onResult(event:*):void
public function onFault(event:*)void
On 7/3/06, ben.clinkinbeard ben.clinkinbeard@... wrote:
Can someone explain why it is telling me I've implemented the
Responder methods with an incompatible signature?
public function onResult(event:ResultEvent):void
public function onFault(event:FaultEvent):void
The signatures shown in the docs are
public function onResult(event:* = null):void
public function onFault(event:* = null):void
What am I missing here?
Thanks,
Ben
--- In [EMAIL PROTECTED]ups.com
flexcoders%40yahoogroups.com,
der_kotty kotty.tm@ wrote:
Hi,
I was just wondering why the com.adobe.cairngorm.business.Responder
interface has been changed since it has been released on Adobe
Labs.
In Cairngorm 2.0 alpha (org.nevis.cairngorm.business.Responder)
the
parameters of the onFault and onResult handlers were typed
events
(ResultEvent and FaultEvent).
Why have the parameters been changed to '*'? Where is the sense
in
that? To my opinion this is not really best practice
Re: [flexcoders] Re: Cairngorm Responder interface changes
Sending again; sent at like 10:00am this morning,
but still don't see it. 10:03pm now.
-
1. ResultEvent FaultEvent events. I
disagree with this change, so have changed them backinstead ofof
using the * changefor the Responder interface.
2. Command callbacks. Sometimes, there is a
legitimate need for a View to "know" when a Command is completed. In my
consulting, we've added an optional callback method that can be passed via
EventBroadcaster (Cairngorm 1). So, View's launching Commands have the
option of using a Callback (like flash.net.Responder) to have a result method
called when the Command is done. We extended Cairngorm's command to have
all of this plumbing hidden. The convention we have is, "If the View has
his onResult run, he can conclude that the Command succeeded in it's
operation." If a fault was fired in the Delegate, this means the app is
broken and needs to be fixed. There is no error handling, only error
fixing.
In my personal work, I've implemented both; result
and faults, via Event's. If an event extends my JXLEvent class (which
extends Cairngorm), it has the option of getting those callbacks. I should
probably do it like we do it at work, but for now, it works. I like
handling errors, so although fault and result are pretty low level, I can have
View's handle errors (or Commands obviously).
Both avoid ViewLocator via a nice convention.
It also makes it cake to have a chained command with visual feedback. You
can have your View fire off other commands in a particular order AND show visual
feedback the whole time. Could you do this by binding? Sure,
butI'd rather use functions vs. state variables.
3. Added 2 methods to ServiceLocator. He
doesn't support Producer or Consumer (MessageAgent) services, so with a new
method he does. He also doesn't support NetConnection; with the new
method, he does. Since Cairngorm was made for a more request response, it
feels like both of the above are halfway implemented, but for sending messages,
Cairngorm works great, including Acknowledge messages for Delegates that fire
the original message. In both cases, actual callbacks are handled by
totally different classes that basically act as Observers, and emit
events. The more specialized (for example, a channel in FDS created for
Text messages, and thus Chat only) is an extension of that ConsumerObserver
class, called ChatObsever, and he omits Chat specific events for those who
care. They, like Delegate's, utlize ServiceLocator.
I would, however, prefer you all either give me a
better idea(s), christen this idea as good for handling NetConnection / FDS'
consumer/producer model, and/or implement something that supports these push
based technologies into Cairngorm.
With the exclusion of #1, both #2, and #3 can be
done via extneding the Cairngorm base classes so you're not affecting the
original framework, only extending it. I'd prefer #3 be made official
though, by you all somehow, some way.
- Original Message -
From: Steven Webster
To: flexcoders@yahoogroups.com
Sent: Monday, July 03, 2006 6:03 PM
Subject: RE: [flexcoders] Re: Cairngorm Responder interface
changes
Jesse,
I'd love for you to share the modifications you're making
to Cairngorm, and to understand the rationale behind these changes. It's
not our intention that developers would typically need to change the
framework locally, and doing so certainly makes it more difficult for folks to
follow us on any upgrade paths as time rolls by. Different strokes for
different folks though.
But if you can share your motives for changes, and the
changes themselves, then we can consider rolling them into the framework if they
satisfy general concerns.
Best,
Steven
Steven WebsterPractice Director (Rich
Internet Applications)Adobe ConsultingWestpoint, 4 Redheughs
Rigg, South Gyle, Edinburgh, EH12 9DQ, UKp: +44 (0) 131 338
6108
m: +44 (0)7917 428 947[EMAIL PROTECTED]
From: flexcoders@yahoogroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of
JesterXLSent: 03 July 2006 20:13To:
flexcoders@yahoogroups.comSubject: Re: [flexcoders] Re: Cairngorm
Responder interface changes
Don't have Flex 2 open in front of me ( client hearts 1.5 ), but you can I
think do:public function onResult(event:* =
null):void{ResultEvent(event).result// or...var
yourEvent:ResultEvent = event as ResultEvent;}I can't
remember if you can cast in the function signature as:public function
onResult ( event:* as ResultEvent = null )...but, either way, you can
also do what I do; keep your own build of Cairngorm locally! I've yet to
work on a project where the team didn't modify their build of Cairngorm to
suit their needs.- Original Message - From:
"ben.clinkinbeard"
[flexcoders] Re: Cairngorm Responder interface changes
Can someone explain why it is telling me I've implemented the Responder methods with an incompatible signature? public function onResult(event:ResultEvent):void public function onFault(event:FaultEvent):void The signatures shown in the docs are public function onResult(event:* = null):void public function onFault(event:* = null):void What am I missing here? Thanks, Ben --- In flexcoders@yahoogroups.com, der_kotty [EMAIL PROTECTED] wrote: Hi, I was just wondering why the com.adobe.cairngorm.business.Responder interface has been changed since it has been released on Adobe Labs. In Cairngorm 2.0 alpha (org.nevis.cairngorm.business.Responder) the parameters of the onFault and onResult handlers were typed events (ResultEvent and FaultEvent). Why have the parameters been changed to '*'? Where is the sense in that? To my opinion this is not really best practice but maybe there's a really good reason for that? Does anyone know? Cheers David Yahoo! Groups Sponsor ~-- Yahoo! Groups gets a make over. See the new email design. http://us.click.yahoo.com/XISQkA/lOaOAA/yQLSAA/nhFolB/TM ~- -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [flexcoders] Re: Cairngorm Responder interface changes
you need to change these lines public function onResult(event:ResultEvent):void public function onFault(event:FaultEvent):voidto this... public function onResult(event:*):void public function onFault(event:*)voidOn 7/3/06, ben.clinkinbeard [EMAIL PROTECTED] wrote: Can someone explain why it is telling me I've implemented the Responder methods with an incompatible signature? public function onResult(event:ResultEvent):void public function onFault(event:FaultEvent):void The signatures shown in the docs are public function onResult(event:* = null):void public function onFault(event:* = null):void What am I missing here? Thanks, Ben --- In flexcoders@yahoogroups.com, der_kotty [EMAIL PROTECTED] wrote: Hi, I was just wondering why the com.adobe.cairngorm.business.Responder interface has been changed since it has been released on Adobe Labs. In Cairngorm 2.0 alpha (org.nevis.cairngorm.business.Responder) the parameters of the onFault and onResult handlers were typed events (ResultEvent and FaultEvent). Why have the parameters been changed to '*'? Where is the sense in that? To my opinion this is not really best practice but maybe there's a really good reason for that? Does anyone know? Cheers David __._,_.___ -- 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 Web site design development Computer software development Software design and development Macromedia flex Software development best practice 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. __,_._,___
Re: [flexcoders] Re: Cairngorm Responder interface changes
Don't have Flex 2 open in front of me ( client hearts 1.5 ), but you can I
think do:
public function onResult(event:* = null):void
{
ResultEvent(event).result
// or...
var yourEvent:ResultEvent = event as ResultEvent;
}
I can't remember if you can cast in the function signature as:
public function onResult ( event:* as ResultEvent = null )
...but, either way, you can also do what I do; keep your own build of
Cairngorm locally! I've yet to work on a project where the team didn't
modify their build of Cairngorm to suit their needs.
- Original Message -
From: ben.clinkinbeard [EMAIL PROTECTED]
To: flexcoders@yahoogroups.com
Sent: Monday, July 03, 2006 3:00 PM
Subject: [flexcoders] Re: Cairngorm Responder interface changes
Ah ha. Actually, I had to change them to
public function onResult(event:* = null):void
public function onFault(event:* = null):void
so that they matched the signature exactly. I guess my confusion was
in that I was viewing the :* as meaning the developer could specify
whatever type they wanted. I was seeing * as a kind of superclass when
that is in fact not the case. I have to agree with Jester; I don't
really see the point of this change.
Thanks for your help,
Ben
--- In flexcoders@yahoogroups.com, Clint Modien [EMAIL PROTECTED] wrote:
you need to change these lines
public function onResult(event:ResultEvent):void
public function onFault(event:FaultEvent):void
to this...
public function onResult(event:*):void
public function onFault(event:*)void
On 7/3/06, ben.clinkinbeard [EMAIL PROTECTED] wrote:
Can someone explain why it is telling me I've implemented the
Responder methods with an incompatible signature?
public function onResult(event:ResultEvent):void
public function onFault(event:FaultEvent):void
The signatures shown in the docs are
public function onResult(event:* = null):void
public function onFault(event:* = null):void
What am I missing here?
Thanks,
Ben
--- In flexcoders@yahoogroups.com flexcoders%40yahoogroups.com,
der_kotty kotty.tm@ wrote:
Hi,
I was just wondering why the com.adobe.cairngorm.business.Responder
interface has been changed since it has been released on Adobe Labs.
In Cairngorm 2.0 alpha (org.nevis.cairngorm.business.Responder) the
parameters of the onFault and onResult handlers were typed events
(ResultEvent and FaultEvent).
Why have the parameters been changed to '*'? Where is the sense in
that? To my opinion this is not really best practice but maybe
there's a really good reason for that? Does anyone know?
Cheers
David
--
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
Yahoo! Groups Sponsor ~--
Something is new at Yahoo! Groups. Check out the enhanced email design.
http://us.click.yahoo.com/SISQkA/gOaOAA/yQLSAA/nhFolB/TM
~-
--
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
* To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/
* To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
* Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
[flexcoders] Re: Cairngorm Responder interface changes
I got arround this issue by changing the interface to read: public function onResult(event:ResultEvent = null):void (dont forget the ResultEvent Import) This is much like cairngorm 2beta3 as far as I am aware (fyi: this strange change is an issue already raised in flexcoders.) -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
[flexcoders] Re: Cairngorm Responder interface changes
I agree. These justifications do not convince me either. Thanks for your response, JesterXL. Very helpful :) --- In flexcoders@yahoogroups.com, JesterXL [EMAIL PROTECTED] wrote: The justifications listed here are pretty weak. http://weblogs.macromedia.com/auhlmann/archives/2006/07/cairngorm_2_for.cfm RemoteObject, WebService, and HTTPRequest all return ResultEvent FaultEvent events. It's also cake to have stubs return ResultEvent FaultEvents for testing services before they are written. Finally, who the heck is using Cairngorm 2 without the the Flex framework? To me, the last argument is the only thing that is even remotely justifiable. - Original Message - From: der_kotty [EMAIL PROTECTED] To: flexcoders@yahoogroups.com Sent: Sunday, July 02, 2006 8:30 PM Subject: [flexcoders] Cairngorm Responder interface changes Hi, I was just wondering why the com.adobe.cairngorm.business.Responder interface has been changed since it has been released on Adobe Labs. In Cairngorm 2.0 alpha (org.nevis.cairngorm.business.Responder) the parameters of the onFault and onResult handlers were typed events (ResultEvent and FaultEvent). Why have the parameters been changed to '*'? Where is the sense in that? To my opinion this is not really best practice but maybe there's a really good reason for that? Does anyone know? Cheers David -- 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 Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
