No worries.
At a high level:
- custom event classes. I extend Cairngorm event. My event has a
resultHandler & faultHandler protected properties. These are the last 2
parameters in the constructor:
p_result:Function, p_fault:Function
Sometimes I utilize type as the first parameter, sometimes not. It's easy
to re-factor if you add additional even types (like MouseUp vs. MouseDown
for example).
- These events work with View's via dispatchEvent, and if used in
Cairngorm's event dispatcher, they run commands. So, they are
interchangeable.
- I extend Cairngorm's Command class and have it do a bunch of plumbing.
You have the option of calling super.onResult ( stuff ) or super.onFault (
stuff ) at the end of your Command's function, whatever that may be
(execute, yourResult, etc.). The onResult will fire the result function you
passed into the Event, and the onFault will fire the fault function. This
allows views to have a specific result function called as well as a fault,
as dictated by the Command. This is how a View can "know" a Command is
done. The Command has the choice to call onResult, as well as the choice as
to "what" to put in it. My convention is the same as Delegates; ResultEvent
& FaultEvent. They are built-in classes, easy to use, and have short
package names. They also work with the new ways we all want Cairngorm's
Responder to go to.
- The Delegate does something similiar; the base class handles the responder
passed in (mine, not Cairngorm's). The Delegate can call responder.onResult
as normal. The Commands can intercept that via their delegate creation, or
ignore it. If they ignore it, the event can go right on down the chain back
to the View.
There is some potential abuse with the above 2. First off, having
Delegate's give stuff to View's feels "dirty". They shouldn't be doing
this. There is no reason you couldn't easily shut off this security breach
by making sure in the Delegate's base class this can't happen. However, I
follow my own convention, so it isn't a problem. This doesn't make it ok.
Second, you have the potential of getting ResulteEvents & FaultEvents with
"too much info". The commands should really only pass true, but even then,
"onResult" is assumed to be "ok" by convention. This doesn't mean it is,
and should probably be formalized. I hate formalities... not in code,
though, so.. maybe... :: shrugs ::
That's it. Psedo is like:
var doStizzNuffEvent:BooYaEvent = new BooYaEvent ( BooYaEvent.KICK_PUNCH,
"someValue", onResult, onFault);
CairngormEventDispatcher.getInstance().dispatchEvent ( doStizzNuffEvent );
function onResult(event:ResultEvent):void
{
// Command's done
}
----- Original Message -----
From: "Tim Hoff" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, July 10, 2006 5:42 PM
Subject: [flexcoders] Re: Accessing a datagrid inside a different viewstate
Yeah, sorry to infer that you weren't conforming to Cairngorm. Any
chance you could show us how you are using the command callback? I
was thinking about doing something like this with
eventListeners/dispatchers, observe or changeWatcher, but a
responder class would be perfect. Not really sure how to do this.
-TH
--- In [email protected], "JesterXL" <[EMAIL PROTECTED]> wrote:
>
> Everytime I started to answer, you pretty much identified exactly
my
> response in your following paragraph.
>
> For some View's, sure, just bind it to a ModelLocator, and you're
good.
> Others are too nested, and need context, which forces you to move
the logic
> higher up to prevent too much coupling. As you say, depends on
scope.
>
> To confirm, I DO use Cairngorm 1 & 2 in my day job & personal
work. The
> only thing I do differently is Command callbacks, and use my own
responder
> class. Both of those are extremely minor points, and anyone using
Cairngorm
> wouldn't immediately recognize those things as non-Cairngorm.
>
> It all "depends" as you say.
>
> ----- Original Message -----
> From: "Tim Hoff" <[EMAIL PROTECTED]>
> To: <[email protected]>
> Sent: Monday, July 10, 2006 4:37 PM
> Subject: [flexcoders] Re: Accessing a datagrid inside a different
viewstate
>
>
> Ok, after a little more thought. Yes, you had me at encapsulation.
> But, "the View's shouldn't know about ModelLocator..",
>
> :: scratches head ::, but Views should be bound to the ModelLocator
> for state?
>
> I can see the logic working for the small DataProvider question
that
> started this thread. If a sub-view is small enough this works fine
> and the view is easily shared with no reference to the
> ModelLocator. However, if the sub-view includes multiple controls
> that have different DataProviders; like a DataGrid and several
> filter combo boxes, it starts to become redundant. Add to that,
the
> sub-view may also have states. In the absence of callbacks, you
> would also have to pass along binding of the currentState variable
> in the sub-view's outer definition. And what about sub-views that
> also have sub-views as components; more passed variables?
>
> As the passed number of ModelLocator references grows inside the
sub-
> view, you could use the approach that I mentioned,
> model="{ModelLocator.getInstance()}". But, this would require the
> sub-view to import the ModelLocator for definition of the model
> variable anyway. At a point, it gets cumbersome passing the
> variables down the list instead of getting them directly. No?
>
> So, how to justify: "Views are bound to the ModelLocator for state
> (including data), but (for loose coupling) should hold no reference
> to the ModelLocator."
>
> I guess this depends on scale. If the sub-view is shared with
> several applications, the outer definition of ModelLocator
variables
> would be necessary, since the different application's ModelLocators
> might have different namespaces. However, if the sub-view is just
> shared with other views in the same application, the direct
approach
> seems cleaner. That is unless, you are creating different
instances
> of the sub-view that require separate bound variables.
>
> I don't think that there is an absolute here. Both methods have
> merit in their own way. Jesse, I know that you have a different
> approach altogether, than what is currently supported in Cairngorm.
> I'm just trying to get a feel for how other people are doing this
in
> large-scale applications
>
> Thanks again,
> -TH
>
> --- In [email protected], "Tim Hoff" <TimHoff@> wrote:
> >
> > That makes sense. Especially if the view has several bound
> > variables. In that case, model="ModelLocator.getInstance()". At
> > the very least, it would make the code more readable. Thanks for
> > your point of view.
> >
> > -TH
> >
> > --- In [email protected], "JesterXL" <jesterxl@> wrote:
> > >
> > > I do it because if I don't, my boss yells at me. Something
> about
> > > "encapsulation" and "View's shouldn't know about
ModelLocator...
> > they are
> > > too tightly coupled that way." This allows a master View to
act
> > as an
> > > intermediary controller of sorts, and dictate what view knows
> > about what.
> > > Since our applications are friggin' huge, this allows us to
> easily
> > share
> > > View's throughout. If we shoved ModelLocator in 'em, they
> > wouldn't be
> > > portable.
> > >
> > > This worked great in Flex 1.5, so you really should not worry
> > about
> > > performance in Flex 2... they've optimized this stuff for us so
> > all the
> > > uber-OOP programmer guys don't shoot themselves in the foot
> > performance
> > > wise.
> > >
> > > ----- Original Message -----
> > > From: "Tim Hoff" <TimHoff@>
> > > To: <[email protected]>
> > > Sent: Monday, July 10, 2006 11:53 AM
> > > Subject: [flexcoders] Re: Accessing a datagrid inside a
> different
> > viewstate
> > >
> > >
> > > Hi Jesse,
> > >
> > > I started using this approach because it was used in the
samples.
> > > When I sought to increase the performace of the application, I
> > > noticed a little gain when I bound the source directly to the
> > > DataProvider. By creating an additional [Bindable]
> ArrayCollection
> > > and an additonal reference in the outer description of the
> > > component, it adds to the resources used and instructions. Do
> you
> > > think that it makes sense to use the direct binding approach
> > instead?
> > >
> > > Tim
> > >
> > > --- In [email protected], "JesterXL" <jesterxl@>
wrote:
> > > >
> > > > If the View's, and all parents have a creationPolicy (in the
> case
> > > of Containers) to "all", then it will be created. However, you
> > > cannot depend on creation order 100%; you'll end up with a race
> > > condition somehwere, and pull you're hair out. You're best
> > approach
> > > is to utilize a ModelLocator approach where you're sub-view,
the
> > > datagrid, is bound to data inside the view. This data is
> exposed
> > as
> > > a public property that has the bindable tag (can be a
> > getter /setter
> > > [mutator] also). That way, as soon as the view is created, it
> has
> > > the data it needs.
> > > >
> > > > -- pseduo code --
> > > >
> > > > // ModelLocator class
> > > >
> > > > [Bindable]
> > > > public var my_array:ArrayCollection;
> > > >
> > > > // main view
> > > >
> > > > import ModelLocator;
> > > >
> > > > <view:MyView someData="{ModelLocator.getInstance
> ().my_array}" />
> > > >
> > > > // sub view
> > > >
> > > > public var someData:ArrayCollection;
> > > >
> > > > <mx:DataGrid dataProvider="{someData}" />
> > > >
> > > > Make sense?
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: Joe Stramel
> > > > To: [email protected]
> > > > Sent: Monday, July 10, 2006 10:59 AM
> > > > Subject: [flexcoders] Accessing a datagrid inside a different
> > > viewstate
> > > >
> > > >
> > > > I have a custom component that I created and I have added it
to
> > > the main application. There is a datagrid inside the custom
> > > component. I call the data in the main app, place it in a
public
> > > ArrayCollection and want the datagrid to display the data. My
> > > problem is that the datagrid is in a different viewstate other
> than
> > > the default view and so I get a null reference error when I try
> to
> > > populate the datagrid from the main app. Is there a way to
force
> > > the component to create itself with the main app even though it
> is
> > > in a different viewstate? Thank you
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > 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
------------------------ 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/
