Hi Jos, I read the javaworld article and yeah, the idea behind the pattern is not that bad. Also I always liked the MVC pattern. They have both their strengts and weaknesses.
What I do not like is the implementation on flashcoders. It is definitely a nice experiment to setup a bidirectional association that automatically routes method calls to the other object if it does not exist using __resolve, but this brings a lot of flaws with it.
1. One does not know which methods he can call on either of the objects, unless he takes a look at the classes of both objects.
2. One cannot type to any of the objects' class because this would result in a compiler error if one called a method that does not exist on the class (unless he used the 'dynamic' keyword for the class which switches type-checking off ;) ).
3. It is hard to follow the program flow because it is not that obvious what is going on.
4. One should not be able to invoke every view specific methods on the model. For example startFill etc. with MovieClips as View.
Greetings,
Simon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have been talking with a couple of other flash dev's about this "pattern". I read about it here:
http://www.javaworld.com/javaworld/jw-09-1999/jw-09-toolbox.html
Here is an example in AS of this kind of thing:
http://chattyfig.figleaf.com/mailman/htdig/flashcoders/2005-March/134287.html
Hi Jos, I read the javaworld article and yeah, the idea behind the pattern is not that bad. Also I always liked the MVC pattern. They have both their strengts and weaknesses.
What I do not like is the implementation on flashcoders. It is definitely a nice experiment to setup a bidirectional association that automatically routes method calls to the other object if it does not exist using __resolve, but this brings a lot of flaws with it.
1. One does not know which methods he can call on either of the objects, unless he takes a look at the classes of both objects.
2. One cannot type to any of the objects' class because this would result in a compiler error if one called a method that does not exist on the class (unless he used the 'dynamic' keyword for the class which switches type-checking off ;) ).
3. It is hard to follow the program flow because it is not that obvious what is going on.
4. One should not be able to invoke every view specific methods on the model. For example startFill etc. with MovieClips as View.
Greetings,
Simon