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" <[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 > > > -- 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/
