运行时上下文¹

运行时上下文是Moqui API的应用核心接口部分。运行时会独立的创建一个上下文实例去执行边缘的构件，如界面或者服务。运行时上下文，或者简写为“ec”，拥有各种门面的接口去曝露各种框架的功能和工具。

上下文同时也维护着一个上下文的map用来呈现每个构件运行的可变空间。这个上下文map是一个map的堆栈，每个构件执行在一个干净的map中，并入栈，一旦构件结束运行即出栈。每当读取这个map栈都将从头开始向下遍历直到找到符合条件的map条目。当写这个map栈时，总是在栈的顶部去执行写操作（除非明确的指定参照根map，例如在栈底的map）。

通过这种方式，每个构件无需担心其他构件的影响，但是构件仍然具有很容易的去访问父构件的数据（通过调用构件链的方式调用或者包含方式，能够向下找到当前的构件）。由于上下文是为了每个边缘构件的执行去创建的，所有它拥有构件运行的详实信息，如：什么时候启用，包含的用户，构件携带的信息等等。

构件栈²

每个构件在运行时或者包含、调用其他构件时，这个构件都会即时的被压入栈中。这个栈始终维持着当前活动的构件的轨迹，同时构件的执行信息也会被添加到一个构件使用情况的追踪历史列表中。

当构件入栈时，每个构件都需要进行鉴权，同时构件关联的安全信息也会被追溯记录。通过这种方式，权限设计就变得很简单了，包含的构件、被调用的构件都能够继承相应的权限。这种权限继承的机制带来的好处是你只需配置并控制直接能访问的关键界面或者服务就可以了（注：这意味着内部调用的其他界面或者逻辑服务无需关心鉴权，会直接继承调用者的权限）。

管中窥豹，可见一斑³

在使用Moqui框架进行开发时，你将会经常用到高度抽象的业务构件，如XML定义文件。这种设计方式是为了一方面支持很多通用的需求，同时另一方面也是为了能灵活的在任何点上都可以向下落到低层级的工具上，如模板、脚本等。在某些点上，你也许希望了解到框架内部到底在做什么，或者当你遇到了一个问题时，如果你明确知道框架内部的处理机制你能更容易定位处理问题。

然而服务和实体定义通过代码进行控制；其他的构件比如XML动作以及XML界面和表单是通过FreeMarker模板的宏定义去转换处理成其他文本方式去渲染的。XML动作（Actions）定义会被转化为简单的Groovy脚本，然后被容器编译成class文件，并进行缓存和执行。XML界面和表单中显示的部分（widget组件）同样会通过模板被转化为特定的输出类型（html，xml，xsl-fo,csv,text等等）。

通过这种形式，你能够很容易的看到通过模板生成的输出结果，并且通过简单的配置，你甚至可以制定你自己修改的模板或者扩展开箱即用的功能点。