Swiz Glossary View – Autonomous View to Presentation Model

December 30, 2009

An overview of Presentation Patterns for Flex was discussed on the adobe blog.

The standard flex program implementation typically uses the Autonomous View presentation pattern.

  • State is in the view
  • Logic is in the view

There is a lot of discussion on how Flex is built for the Presentation Model. Users for both the Mate and Swiz framework have gravitated toward this implementation.

  • State is in the presentation model
  • Logic is in the presentation model
  • View observes the model and is updated accordingly
  • View knows about the presentation model
  • Presentation model does not know about the view

My current implementation of the Swiz Glossary view program was done apparently using the Autonomous View pattern. (I did it without really realizing it:)

In an attempt to better understand the differences, I went back and converted the Autonomous View version into the Presentation Model version using swiz.

The view source is enabled in the examples above to compare the differences.


Swiz vs Mate ViewStack – Replace Dummy Glossary View with Live Version

December 9, 2009

Now that I have a simple UI ViewStack framework configured, it is now time to test the incorporation of actual data into the Glossary view portion of the view stack.

I took a standalone flex based Glossary application which had been implemented outside of any framework(beside the flex framework). It uses an xml loader class which I use when coding in both Flash CS4 and Flex. Flex has a nice builtin HTTPService call with an ASyncToken feature but it is not usable in Flash CS4 so I standardized my xml based file loading requests around my hand rolled xml loader class.

I converted the Glossary application to a Glossary component and incorporated it into the Swiz based application framework first. You can view the swiz based resources player here. The view source is enabled, so just right click on the flex application to check it out.

I then incorporated the same Glossary component into the Mate based application framework. You can view the mate based resources player here. The view source is enabled, so just right click on the flex application to check it out.

Now this conversion was quick and dirty but it was much faster to do in Swiz. I could use more of my original work(code) without much change when I wired it up in Swiz(By throwing in a few autowire and mediate metadata tags). When I did the same conversion in Mate, I had to make more modifications to my views and the EventMap was very verbose. I also had to research which Mate based tags I needed to use in the EventMap and how to use them. Steeper learning curve.

In essence, with Swiz I seem to be coding to solve the problem instead of coding to the framework.

Compare the following files between the two framework versions to illustrate the difference:

  1. ResourcesBeans.mxml(Swiz) vs EventMap.mxml(Mate)
  2. ResourcesAppController – compare the code in both versions
  3. ResourcesModel in Swiz was distributed into two Files in Mate Version – ResourcesView and ResourcesAppController
  4. GlossaryView.mxml

Note: I also added an error view that displays a message if the xml data was not loaded properly.

Swiz vs Mate in a Simple Flex based ViewStack Example

December 8, 2009

In my previous post, I implemented a ViewStack control using Swiz. You can review my first example of using the Swiz framework to toggle between the views in a ViewStack here. The view source is enabled, so just right click on the flex application to check it out.

After completing the Flex ViewStack example in Swiz, I then massaged it to be rendered using Mate. The ViewStack example can be viewed here. The view source is enabled, so just right click on the flex application to check it out.

I guess the benefit of using Mate, is that you can easily move the project code to another framework since the EventMap centralizes the injection and mediation behavior in a single file.

The migration issue aside, when using Mate I felt like I had to write more code to accomplish the same thing I just wrote in Swiz. The EventMap and Mate framework require more verbosity to link up the models and event mediation than the Swiz bean based framework. Compare the code in the following files in the two examples:

  1. MainResourcesView.mxml
  2. ResourcesAppController.as
  3. ResourcesView.as vs ResourcesViewModel.as
  4. EventMap.mxml vs Beans.mxml

I really like the Swiz implementation even though it is not as centralized as Mate(Event Map usage).

Although you embed the [Autowire] and [Mediate] metadata tags in your code to reference the Bean instances(This embedding may impede your ability to easily transfer code to another framework), the use of these tags lets me know, for example, when I am in a file what model is being referenced and what data is injected immediately and what events are being subscribed to by just looking at the code without having to reference/setup this info in an EventMap or writing extra getters and setters in a view.

I also did not have to think as much about how to use the Swiz framework as I did with the Mate based one. For me, the use of Swiz was more intuitive.

Swiz Simple Flex based ViewStack Example

December 8, 2009

I am currently evaluating IOC(Inversion of Control) frameworks to use at work and have narrowed the choices down to Mate and Swiz. I had looked at the Mate framework before and also wanted to check out the new Swiz IOC framework as well.

I thought I would implement just a gui based viewstack control example before I attempted to load data into the views.

So you can view my first example of using the Swiz framework to toggle between the views in a view stack here. The view source is enabled, so just right click on the flex application to check it out.

I REALLY like the SIMPLICITY of this framework.

I like the use of the [Autowire](injection indicator) and [Mediate](event listener indicator) metadata tags to provide the IOC mechanism along with a Beans.mxml file.

The Beans.mxml object is instantiated on the Flex.PREINITIALIZE step of the code life cycle. The instances created in the Beans object can be shared and referenced by the models, views and controllers code in your project with the use of [Autowire] metadata tag.

This PREINITIALIZE step is also where the introspection engine runs to wire to the variables/functions that have the [Autowired] and [Mediate] metadata tags sprinkled throughout the project code.

In my example, I have two beans(model instance and a controller instance) which can be referenced by the views(to get the model data) and the controller(to update the model and listen for events dispatched from the views). In essence,the information that is to be shared among the models, views, and controllers is centralized in the Beans.mxml file.