art, life and software development

30

I managed a measly 30. Check it out, its the funniest site I've been on in months - Good Idea!

Manchester United harassed and pummelled Arsenal to a 4-0 victory yesterday. I'm a football manager fan so its always a pleasure to see GameMasters Ferguson and Wenger lock horns. Its simply the best of the best in the tactical and passion department as far as football is concerned. Granted these contests always seem to be a bit on the "Tabasco" side but, I must confess I was a bit puzzled about the furore about Nani's (in Mr Wengers view) "provocative showboating". It seemed to me a beautiful piece of skill that was absolutely necessary to keep control of the ball bearing in mind the fact that he was being chased by 2 Arsenal defenders.
Hey do not take my word for it, see the video and make up your mind.

I've been taking a look at the MVC Meta Pattern, again, as one usually does when you have a project that requires its implementation. The Model carries all the business logic required to implement the goals of the triad as a result it possesses a whole gang of custom methods that the controllers have to know in order to communicate with it. HMMMmmmm. In some way I've never really been happy with that as i felt it exposed that unique Model's internal API a bit too much for my liking. There is also the annoying problem caused by instantiating the Concrete Model to an interface, as a result class methods not declared in the IModel interface, through up errors when called by the any deployed controller. One option is to cast to the data type of the Concrete model, that would definitely work. I wondered if a more elegant solution could be deployed, so I went with the idea of a generic function to which you could send the name of the target method as a String along with its parameters. The generic function would then call the real target function. This generic function would be introduced as a declared method in the IModel> The concrete implementation is created in an AbstractModel class along with other concrete implementations if the IModel interface. All Concrete models are subclassed to the AbstractModel class.

IModel interface:

public interface IModel

{

function registerObserver(o:IView) :void;

function removeObserver(o:IView): void;

function notifyObservers():void

function genericfunction(func:String, ...rest):void;

}


This solution introduced a new kink, what happens when the wrong string is sent? The solution lies in the Proxy class. This class allows you override the default behavior of ActionScript operations, however my interest in this class is to use it as a sweeper class to fire a default function and thereby deal with bad string arguments elegantly. We implement the Proxy by subclasing it as an inline class (class only visible to the AbstractModel) to the AbstractModel. The subclassed Proxy then has the callProperty overridden to fire a default function.


dynamic class MLPModelProxy extends Proxy {

override flash_proxy function callProperty(methodName:*, ... args):* {

var res:*;

switch (methodName.toString()) {

default:

trace(nofunction())

res = nofunction()

break;

}

return res;
}


public function nofunction():String {

return "NO FUNCTION"

So it works like this bad string is sent from controller as argument to genericFunction, a try, catch passes the error via a ReferenceError event object. In the catch block an instance of the subclassed Proxy passes the flawed string and fires the noFunction() method.