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" <[EMAIL PROTECTED]> 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
> >
>
------------------------ 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/
