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
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:
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
-
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
ROTECTED]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
ianninas@
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 r
mailto:flexcoders%
40yahoogroups.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
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
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
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
.
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
, 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
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?
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
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
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
: [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
: [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
.
- 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
ahoogroups.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
[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
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
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
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:
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:
25 matches
Mail list logo
