commandMap.mapEvent(ContextEvent.STARTUP,StartupCommand,ContextEvent,true)
参数1：事件名称
参数2：处理该事件的command
参数3：事件类型
参数4：是否只处理一次该事件。默认为false
该函数是将 事件 映射 到command。robotlegs就会自动的new一个command并自动调用他的execute方法。
mediatorMap.mapView(Ball,BallMediator);
参数1：视图
参数2：接受处理该视图的事件
该函数是将view和mediator映射起来。
eventMap.mapListener(ball,MouseEvent.CLICK,clickHandler);
参数1：事件派发者。也就是这个事件是谁发出的。例如点击小球。小球就是时间派发者
参数2：事件名称。这里是鼠标点击事件
参数3：处理该事件的函数
该函数其实就是等价于
ball.addEventListener(MouseEvent.CLICK,clickHandler);
前者的好处是框架管理。不用自己去释放监听器。后者是原生的。你需要考虑结束释放的问题。
事实上。笔者认为这个框架是利用事件来传递的。不管哪个mvc哪个层。都是可以来接受事件。发送事件。这样做的好处。无非就是可以有一个总管。姑且这么叫吧。每个部分只要关心自己关心的东西。当总管看到有你关心的事情。他就通知你了。
笔者总是认为
commandMap.mapEvent 和 eventMap.mapListener
是很相像的。都是来绑定事件到处理它们的函数或者command。但是笔者浅显的觉得。commandMap.mapEvent这个功能就是实现了控制和显示的分离。command是控制层的实现。笔者习惯在command中来对数据操作。然后发送事件让mediator来接收。mediator接收了事件。就会通知view来更新。
举个简单的例子。
点击小球。然后会显示两个。再点击。显示三个。有一个文本。来显示小球个数。
首先是在小球的mediator也就是ballmediator中为小球绑定一个事件监听器。也就是eventMap.mapListener，如上所说。他有一个事件的处理函数。我将在事件处理函数中广播一个事件。这个事件是我们自己定义的。正因为是自己定义的。所以我们知道这个事件就表示了小球被点击了。如此一来。我们就可以在最开始的 项目名context中用commandMap.mapEvent来绑定事件到command上。这里就叫createNewBallCommand。也就是说。你点击了小球。最终这个事件就传到了createNewBallCommand这个类中。当然。这个是框架帮我们实现的。我们只要知道。它就是这样的。而且这个事件一发生。框架就会调用createNewBallCommand的execute方法。哦。不对。框架怎么知道我们有这个方法。显然。因为这个方法是command的。而我们的createNewBallCommand是继承自command而来。所以一般重写该方法。来操作数据。怎么操作呢。这个时候就想到了m。就是模型层了。模型层。说白了就是封装数据的。这里很简单。就是一个计数的变量。我们把它写成一个类就ok了。于是依靠着框架提供的依赖注入。我们得到了这个model的对象。对了。要说明的是。我们一般获取的会是这个对象的单例。因为这份数据在视图中也是要使用的。有了对象就可以轻松为计数加上一了。然后要做的就是发送事件。是的。又是事件。和上面一样。我们自己约定一个事件。就叫 计数加一完毕 这个事件一广播。框架就给我死命的找。这个事件绑定了哪个command了。但是此时。好像不对了。为什么？command是控制层。来操作数据的。数据操作完成了。还找command干什么。是不是该轮到mediator登场了。还记得上面的ballmediator么。是的。这个是绑定了小球这个视图的。要通知它。我们数据更新完了。你得去告诉view。去更新吧。但是框架怎么知道哪个mediator对这个事件敢兴趣呢。于是再次用到了eventMap.mapListener。如此一来。框架就可以找到对这个敢兴趣的mediator了。然后执行对应的事件处理函数。在事件处理函数里。再次发送事件给view。一样的套路。从而让view来更新视图了。
