3

Coming from Robotlegs/PureMVC, I am pretty familiar with the concept of the view mediator, i.e. a component that pretty much listens to events/requests coming from the "dummy" view and makes a further request, sends an application-wide signal/event, executes a command, etc, based on the request from the view.

Can the host component idea introduced in Flex 4 be considered a the same as a mediator? The only thing that slightly bothers me is that host components are still considered views, because they extend SkinnableComponent or any of the classes that further inherit from it. In my view, the mediator should be completely left out of view logic.

Nevertheless, I do not want to write a skin, a host component, and a view mediator for that host component, because that would be quite an overhead, and would lead to more complexity rather than abstraction.

Should I use host components as mediators, and put application-level logic there, for instance application level event dispatching?

zero323
  • 322,348
  • 103
  • 959
  • 935
user802232
  • 2,541
  • 7
  • 34
  • 40

1 Answers1

1

I am troubled by this in the SkinnableComponent pattern as well. I like my behavior to live in classes that are not view components. I don't even like having references to view components, so I tend to prefer the "Presentation Model" pattern. With SkinnableComponent, the host component is still a view component, but it holds all of the shared behavior. It feels like a bit of a mess and I am not a huge fan of this. I do, however, feel like it is a pretty good way of building re-usable, skinnable components. It is great if you are a component developer, for instance.

That being said, I find it to be way too complicated to have a Skin, a Host Component and a separated behavior class. Because of this, I tend to just stick with the pattern they gave us (Skin and Host Component) for skinnable components. It makes testing more complicated, in my experience, but it is what it is.

If I don't need a SkinnableComponent (because I am not generally creating skinnable components for external consumption), I simply use a separated presentation pattern (usually PM) and forgo the skinning pattern.

Brian Genisio
  • 47,787
  • 16
  • 124
  • 167
  • +1 from me; although I also question how "great" it is for component developers. Extending the Spark Architecture still has all many of the issues that extending the MX Architecture had; except now things are thrown around between many different classes and it is ever harder to figure out what's going on. – JeffryHouser Jul 17 '11 at 15:31
  • @www.Flextras.com: Good point. I am coming from an perspective where I am comparing it to "templating" in Silverlight. I like the skin class approach better because it allows you to derive from existing skins in order to change a single property (as opposed to copying the entire template and changing one property as in Silverlight). The object-oriented approach is what I think is nice. But I do agree, there is a lot of friction, still, with the "skinnable component" pattern in Flex4. – Brian Genisio Jul 17 '11 at 15:38