Very cool, Coding this will be a good learning experience.
Thanks, Tim --- In [email protected], "JesterXL" <[EMAIL PROTECTED]> wrote: > > 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" <jesterxl@> 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" <TimHoff@> > > 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 > -- 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/
