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 flexcoders@yahoogroups.com, "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: <flexcoders@yahoogroups.com>
> 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 flexcoders@yahoogroups.com, "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 flexcoders@yahoogroups.com, "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: <flexcoders@yahoogroups.com>
> > > 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 flexcoders@yahoogroups.com, "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: flexcoders@yahoogroups.com
> > > > 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
<*> 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/
