What's new in 0.8.5

I added 2 new tags to the framework: "ListenerInjector" and "CallBack". I'm thinking that those tags will replace the Dispatcher-Response tags and the Listener tag in the near future. I'm thinking in deprecating the old ones but first I want to listen your thoughts about that.

Before entering in details about how "ListenerInjector" and "CallBack" work, let me recap the history of the Listener, Dispatcher, ResponseHandler and ServiceResponseHandler tags. All those tags are what I call view tags. They usually are placed inside a view and allow the view to communicate with the rest of the app and listen to responses or events that happen outside the view instance. These tags are old, they were created long time ago before even the injectors tags existed and when the communication from and to the views was based on other pattern, not the IOC (inversion of control).

The problem with those tags is that every time that you use it, you create a dependency between your view and Mate. As all you know, we try to keep the view as clean as possible and avoid any reference to the framework. You may want to reuse that view for example on another project or maybe you want to change frameworks and you don't want a dependency on each of your views.Because of that, I created 2 new tags to replace the old ones.

Listener tag vs ListenerInjector:

The main difference between these 2 tags is that Listener is used inside the view and ListenerInjector is used inside your Injectors in your EventMap. Both do the same, register an object to listen to events dispatched from another object (the dispatcher). But the difference is that with ListenerInjector, you don't have to have any reference to Mate in your view.

With the ListenerInjector you can choose what dispatcher you want to use, default being the dispatcher available in the EventMap. And you also have the typical parameter of the addEventListener function call like:

  • priority:int |0|
  • eventType:String
  • useCapture:Boolean |false|
  • useWeakReference:Boolean |true| We are using true because we don't want to keep any reference. You can override that if you need it.

Code Example:

<EventMap>
<Injectors target="{MyViewClass}">
<ListenerInjector method="myMethod" eventType="{MyEvent.EVENT_TYPE}"/>
</Injectors>
</EventMap>

Dispatcher + ResponseHandler + ServiceResponseHandler vs CallBack

You get 3 in one here ;)

Following the same idea, the CallBack is a tag that you use in the EventMap, while the other 3 tags are used on the view. They do similar things, though not exactly the same, but you can accomplish the same tasks. Before, if you wanted to have a response when you were dispatching an event from a view, you needed to use a combination of a Dispatcher tag plus a ResponseHandler or ServiceResponseHandler. Now you just dispatch the event normally, letting it bubble up from the view (no tags on the view) and in your event map inside your EventHandlers, you can use the CallBack tag that will execute a method in the target object that dispatched the event. You can pass any number arguments (don't need to create an extra event) similar to the MethodInvoker tag, but instead of creating an instance and then calling a method, you just call a method on the target object. In this way, you can, for example, remove a progress bar after the server responds by using a CallBack to the view that dispatched the event.

Code Example:

<EventMap>
<EventHandlers type="{MyEvent.EVENT_TYPE}">
<CallBack method="myMethod" arguments="{myArgument}"/>
</EventHandlers >
</EventMap>

This will not replace any of the other patterns that you may use to decouple your views like PresentaionModel, ModelAdapter, etc. This is just another tool in your box.

My next task is to upgrade all the examples in the site to follow this new approach.

12 responses

  1. Good riddance to the old view tags! Less dependencies for all!
  2. Yes.
    I agree with Theo.
    The only issue I could foresee is one of timing, but I am sure that you are way ahead on that.
    I look forward to doing some new testing.
  3. very nice...
  4. Finally ;)
  5. Hi Nahuel, first thanks for this framework!...Now I understand the idea of removing the mate tags from the view, but could you, please, explain how the view its going to comunicate with the even map, because before this version we used the dispatcher and generate the event (exampleDispatcher.generateEvent()) and then the even map manage that event... tahnks for your help.
  6. Hey guys,

    could you tag this release in the repo?

    Thanks for the great framework - truly a joy to use!
  7. @Carlos, I'm planing to update some of the examples, but basically you just dispatch your event from your view dispatchEvent( new MyEvent(MyEvent.MY_TYPE, true));

    @Ryan, new tag is ready ;)
  8. Hi Nahuel. I have been to trying to use Mate in my current project and I like it alot. My main concern though is that I find huge difficulties when trying to work with dynamically instantiated views and dynamically loaded modules. Injectors seem like a great idea but what do you do if you do not know to the name of the view you are trying to inject to at compile time ?

    For example if an external module is loaded in my app it can currently use the existing Listener Dispatcher and ResponceHandler tags in order to receive data from the main application. I havent used it yet and I am not very fond of the idea of using them but as I understand it it can be done. With the new tags this will be impossible.

    Maybe I dont have a clear idea of the mate philosophy and I am completely mistaken. Your insights are going to be greatly appreciated.
  9. Scratch my previous comment. I had a bad understanding of how the Callback tag works. I really got a grasp of it after reviewing the sample provided at http://code.google.com/p/mate-examples/
  10. Nahuel, I was wondering if you had a chance to resolve the issues with using Mate in AIR when creating a new Window mentioned in a previous post: http://mate.asfusion.com/forums/topic.php?id=274. Does the ListenerInjector or Callback help to resolve this issue? Maybe you have suggested for best practices for creating a Window in AIR and have the events bubble up to the Mate EventMap. Been thinking of switching to Mate but we use a lot of Window views in our application, thanks!

    Michael
  11. @Michael, Yes we are planning to fix it. I added an entry to the uservoice website. You can vote for it to be first on the list. http://mate.uservoice.com/
  12. @Nahuel, Any news? I'd love to see a solution. Thanks, Sanford

Comments now closed