A couple more thought on this and I welcome others to jump in. Here's an example of where a custom event would be preferable to using public properties in components. Similar to Peter Ent's example, let's say that you have four different views that a user could select an order from; a DataGrid view, a TileList view, a List view and a Repeater view. For this example, each component could have a selectedItem public variable, or use a custom event; that has a selectedItem property. It really doesn't matter, but in this case the latter could create less code; especially if you are using getter/setters. So "event.target.selectedOrder" becomes "event.selectedOrder." It's pure preference. But, you simply can't say that one is better than the other, or that tight coupling is involved. It's just not true.
Like I said earlier, for this I would personally use a presentation Model. And in an enterprise application that uses an MVC framework, custom events with attached data are absolutely necessary to communicate across the entire application and with different class types; like Views-FrontControllers-Commands or Views-EventMaps-Managers. Anyway, that's .02. -TH --- In [email protected], "Tim Hoff" <timh...@...> wrote: > > > Don't agree. The smoke test for tight coupling is that if component A > is tightly coupled to component B and you take away component B, you get > a compiler error in component A. By using an event, that doesn't > happen. Component A dispatches an event that component B listens for. > If you take away the listener it doesn't break the dispatcher; and > vice-versa. Sure, the components both reference the event class. But, > with your logic, you're saying that two components that both use > mx:controls:button are tightly coupled together; because they reference > the same class. > > Whether it's a custom event or a regular event makes no difference; > custom events simply extend flash.events.Event. Yes, a little extra > code for the custom event, but not close to being bloat. In fact you > could just as easily use a plain old DataEvent, if you're worried about > that. > > Not disputing that public properties are a viable approach. Just > pointing out that Flex is an event driven framework. > > -TH > > --- In [email protected], "Amy" amyblankenship@ wrote: > > > > --- In [email protected], "Tim Hoff" TimHoff@ wrote: > > > > > > > > > There are several techniques that you can use for this; it really > > > depends on what the need is and the sophistication of the > application. > > > Personally, I would employ a presentationModel to solve this, but > using > > > an MVC framework and VO's can be challenging for some. In this case, > > > using public properties in the components would work fine. > Respectfully > > > though, the assertion that using events creates a "tightly-coupled" > > > strategy is not correct. Tight coupling is where components have a > > > direct dependency on one another. Loose coupling avoids this by > linking > > > the components with properties and/or events. > > > > But if you have a custom event, you have two classes that are > _directly_ dependent on a custom event class. I think it's incumbent on > all of us to understand the principle of loose coupling well enough that > we can generalize and see things that cause unnecessary coupling even if > no one has taken us by the hand and said "hey look--this is also tight > coupling." > > > > > I do agree though, that > > > you wouldn't necessarily want/need to pass data around amongst > > > components, using custom events. This is where the beauty of a Model > > > comes into play. > > > > > > Here's a good article to read, that might help for this solution: > > > > > > http://www.adobe.com/devnet/flex/articles/loose_coupling.html > > > <http://www.adobe.com/devnet/flex/articles/loose_coupling.html> > > > > I think that's a great article, and I think it's important to note > that he doesn't create a custom event to handle this--instead he uses a > generic event and then reads the public property off of the component. > > > > -Amy > > >
