大约在08年年初的时候就知道igenko这个项目的存在，那个时候，还是刚刚起步，不过更新速度很快。
之所以关注这个项目是因为技术架构和springside有很大的互补的地方，两者都使用了spring,但是springside很着重展示后台部分(当然了，这个随着小胖的加入，前台的grid会更强)，而igenko则是更加着重前台展现（它使用了flex作为客户端）。另外，igenko值得关注的原因还有，他使用了jbpm作为工作流，并且项目的目标很明确，一个基于ria展现的cms系统。

本篇关注一下igenko的客户端登陆逻辑。
对于登陆的后台部分逻辑是使用的spring-acegi,所以后台的部分和springside非常的相似，如果谁觉得需要更多了解，直接去看springside的wiki是最省事的了。而前台的逻辑中，igenko试用了puremvc作为其mvc的框架，更有意思的是，bouiaw找了一个prana的开源框架充来当spring的角色，完成ioc的注入。
在puremvc的逻辑中，需要在view（也就是mxml中）触发出事件，而Mediator(view的一部分，相当于view的逻辑部分)来监听这个事件。继而Mediator将会发出Notify。系统中其他地方接收这个通知，继而进行相关的逻辑处理，也就是说，view层的Mediator发送了消息给controll，继而view层退出这个事件了处理。
上边的逻辑大家可以在，org.igenko.client.backoffice.view.common.BackofficeLogin这个类中看到，这个类触发了一下的事件：
dispatchEvent( new Event( BackofficeLogin.LOGIN ) );
而org.igenko.client.backoffice.view.common.mediator.BackofficeLoginMediator则监听这个事件，如下：
backofficeLogin.addEventListener( BackofficeLogin.LOGIN, login );
继而在login方法中，处理逻辑：
这个当中就发送了我说的那个通知。接下来就是controll层来处理这个通知。
而controll层就是puremvc中的commond,按着文档中的逻辑，那个通知触发那个commond是由facade这个接口来负责的。
这个时候就是igenko的一个有意思的地方了。在puremvc的文档中，应该在facade当中将commond注册进去，但是ingeko只是
当中看似没有注册任何关于Login的commond，但是当关注到NotificationConstants.STARTUP_CMD这个commond的时候，就会发现如下的代码：
这说明，facade加入了一个StartupCommand,而StartupCommand又继承了IocManagedMacroCommand这个可以执行多个commond的类，那么就是相当于facade注册很多个commond.
接下来的问题就是，StartupCommand中的_commands这个数组是那里来的呢？
答案就是，ioc注入的。
在ApplicationContextCommon.xml中可以发现如下的配置：
对于当中的registerCommandsCommand是如下的：

可以看见第一个注入的就是loginCommand.

继而，我们可以看见经过一系列的寻找，触发了view层的login事件，最后会到达到 org.igenko.client.common.controller.login.LoginCommand类的excute方法(很类似struts1吧，连方法名都一致)。如下：

接下来就是通过remote object与后端通信了。

希望这个摘记对于刚刚接触的人有帮助。对于文中的不合理之处，欢迎指出！