I’ve come up with a slight improvement on others’ use of Presentation Models in Mate. The idea is that you have your models extend UIComponent, allowing them to both dispatch bubbling events and work as an injector target.
A Little Background
Mate is a fantastic Flex application framework, and has been gaining a lot of popularity over the past year. One useful pattern that works really well with Mate is the Presentation Model pattern.
The idea behind the pattern is that rather than put a bunch of logic (actionscript) in your views, you put it in a class that is related to the view. There are different ways of doing this, but practically it means that the view has a handle on an ActionScript class that contains a bunch of logic.
So — in short — the idea is to keep your views stupid.
The Old Way
I owe everything I know to Iconara (Theo), whose posts on Mate architecture have helped me get started on a variety of subjects, including this one.
In his examples, Iconara has the Event Map create a copy of the presentation model just like it does a manager, which he then injects into the view. I assume he does this so he can inject to it (Mate can only inject to views, and to classes it has in its cache).
He also injects a dispatcher into it, so it can dispatch system events (something you want your presentation model to do). Events will only bubble up to the Event Map if they are in the display tree somewhere, so non-view presentation models need a dispatcher that IS in the display tree.
Why This is Better
Injecting the presentation model works, but it has a couple of limitations. First, the extra logic of injecting a dispatcher is just a tiny bit annoying. More importantly, though, there is only one copy of the presentation model shared among all similar views. Many times this doesn’t matter (views are usually unique), but in one case, we wanted to recreate a view (a popup) every time it was accessed, and the model contained stale data every time. Finally, it is just plain simpler to have the model created by the view.
All I had to do was this:
public class LoginModel extends UIComponent
{
public function LoginModel()
{
this.visible = false;
this.includeInLayout = false;
}
}
By extending UIComponent we acheive bubbling and injection, and by setting it to visible=false and includeInLayout=false, it doesn’t take up any space or show up.
See for Yourself
I have put up an example application. It has a login screen which goes away when you log in, and a model with some of its logic. The model is dispatching the system event.
Note - You can use any username or password. I’m not actually calling a server or anything.
Please let me know if you have any suggestions or comments
12 Responses
Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.
Interesting!
I have extended the EventMap itself to add some Module functionality, but this is different. I will dig deeper later today I think.
Thank you,
Greg
In my Java implementation of Cairngorm (which looks a lot more like Mate than Cairngorm), I use a similar mechanism, with a completely separate processing layer instead of passing it up to the event map singleton. A specific problem with Mate and Cairngorm is where you start having to cram more and more presentation logic (how to make changes to a view) into a view, event, model…there is no clear reason to put it any specific place (now we have another place…managers!) leading to a crapload of actionscript and increasingly deep object trees.
Similar to the presentation model, or my idea of having the presentation model extend a display component?
I was sort of talked out of the idea presented here (although I continue to use Presentation Models with gusto). See this thread for more information.
http://mate.asfusion.com/forums/topic.php?id=352
I agree it can be hard to get everything in the right place, but one of the things I like about Mate is it seems to help me decide, rather than give me too many options. I mean, at least, with a little thought, it’s obvious where some bit of logic should go.
I dont like a couple of things with this.
1. your model extends UIComponent removing any opportunity for it to extend any other class.
2. Its extends UIComponent and enforces the empty constructor rule.
The instantiation occurs in the view and therefore there is no way of passing dependencies through the constructor.
I don’t use this method any more
But yeah, valid points.
Care to tell us what method you use now?
Sure. I went back to the standard Mate way (inject a dispatcher, and inject the pres. model into the view, rather than have your view create it).
I later developed a way to have non-view components dispatch a creation complete event and have it get picked up by Mate (without the registry static). It’s in the biff library.
I’m currently developing with Glue instead of Mate. With glue you would just create the presentation model in the controller, inject it to the view, and route it right in the controller.
http://bifff.seanhess.net
http://glue.seanhess.net
LOL
This article is an anti-pattern I once wrote as an april fools joke, no lie.
MCV - model contains view.
I would abandon this approach as possible if I were you - this is the total opposite of separating your concerns and will lead you to hell on earth..
unless of course, is this a joke?
I did mention that I no longer use this approach, but I think you’re totally missing the point. Are you familiar with the presentation model pattern? It doesn’t take the place of your application model, but is one way of interfacing a view with the rest of the application.
In this example the model doesn’t contain the view at all. The view instantiates a presentation model, not the other way around. The pattern is still a valid one, it’s just the extending UIComponent idea that was abandoned.
I am just new to mate, after reading a lot of articles i am just confsed where to write the logic for opening popup window. Should i write in the parent mxml, but then i would be handling the result of event in the view itself which is a deviation of mate concept.
Please correct me if i am wrong.
This is wrong on so many levels….. Besides it is possible to inject the dispatcher into your presentation model. Sometimes I really wonder about the caliber of FLEX developers out there. I think most must come from FLASH as there seems to be no regard for encapsulation or basic MVC.
@Leigh - shock horror that Flash Developers conversant in AS3 would use those same skills with Flex. I’m one such developer, but after 10 years of AS1/AS2/AS3 and a few years in Flex the mantra of encapsulation, separation of concerns, IoC, blah blah blah has been well and truly drilled into me.
Of course, I’m often left wondering where the line between over architecture and pragmatism needs to be drawn…
Kudos to Sean Hess for continuing the development discussion - it gives all of us “lower caliber” developers a chance to play with know it alls such as Leigh