1. 工作规划：完成系统请假管理的功能。
（1）根据系统需求完成请假管理model；
（2）进行请假流程的deployment；
（3）进行请假流程的流程定义管理；
（4）进行流程配置管理；
（5）发起请假管理模块；
（6）进行请假管理及之后各UserTask任务页面的表单页面编写。
（7）在各级页面设置代理功能
昨天，后面几条没有做完、走通，今天接着做下去。
有几点想法：
1.在lemonOA中，利用activiti引擎来做流程管理，目的自然是为了代码复用。它的思想是任务驱动，什么意思呢？一个流程只要发起之后，之后的每一步都是一个task，都是一个任务。在这种情况下，我们就提取出了一个业务模型，一个流程结构。之后的每一步都可以复用任务（task）部分的代码，只是数据变了，变成任务相关的task数据：表单。
还记得上数据结构课的那个经典公式吗？ 程序=数据结构+算法。在这里，数据结构=表单，或者称之为业务模型。如果这样分，其实粒度比较大，还有一个公式：类型=类型上的数据+针对这个类型数据的操作，这时针对表单的操作方法如下，
如果粒度再小一点，应该是activiti流程引擎驱动流转的各个状态数据，而且此时的业务模型的操作，就是由activiti的API构成。
但是，我感觉这样就有点杂了，很显然操作的粒度变细，但是操作的方法变多，但是操作的数据类型变得多样，xml，表单等等。缺乏一个公共的接口来封装，就像做成java中的I/O流，针对内存的，针对文件系统的，针对网络的。
2.顺着上面的思路，在粒度较大的情况下，这里数据是表单A，操作方法就是针对表单的各个操作B，而整个业务模就是针对表单采用B设计如何操作A的算法。
3.在这里，针对表单的前端显示值得一提。我们上面已经提到，为了能够让代码复用，提取了task模型，然后设计了一整套针对task的API。但是前端显示呢，每个任务的表单是不一样的，怎么显示。可以把url也存起来，然后重定向到不同的url，那么这样的话，我们就是在设计一个个不同的jsp页面，放到不同的目录下面。
如果我们要重定向到一个固定的url呢？那就要把前端jsp页面中的表单数据也放到数据库中，然后在jsp页面中把后台传来的数据进行组装，重新构造dom树。所以，lemonOA代码里java和js中，都会有一套操作前端form组装与显示的代码。
并且现实世界，也没有我们想得那么复杂，就利用各种json数据进行封装就好了。key & value 就能hold住这个世界大部分的应用场景。
第二步 进行流程配置管理
昨天卡在这里了，发觉应该还是对业务不熟，我通过modeler建模器把模型画出来之后，生成了xml文件，然后在部署时将xml进行分解，生成node节点的各个实例并且存入数据库。
可是在后台进行流程配置时，有没有修改xml文件，还是仅仅进行了数据库的insert和update操作呢，不知道。（procdef表会读一次，应该会在内存中生成了一个有向图。xml文件一经部署便不会再改变，改变是通过bpm_前缀表群添加数据来实现的。部署deployer的语义，就是对xml文件进行解析分解。）
所以，今天接着查看mysql的日志，估计要看lemonOA中操作activiti API进行流程运转的各部分。
-------------------------------
avtiviti引擎部分在进行引擎流转时，读一次act_re_procdef，应该是在内存中保存一个状态图模型，然后得到下一个task的位置。
状态流转时，现查identitylink,然后 hi_actinst –> ru_execution –> ru-task ;
-------------------------------
不过搞清楚了一件事儿，就是虽然activiti代码部分，留了tasklistener的接口，但是需要具体的实现，所以在lemonOA的代码里定义了很多不同类型的listener，这些listener需要在数据库中进行保存。这就是bpm_前缀表群存在的意义。
-------------------------------
在这个lemonOA系统中，表单支持文件上传，且文件数据是通过storeConnector进行本地路径存储。
--------------------------------
在进行流程设计时，需要考虑到分支，以及一些自动化跳转的实现，这在实现时，需要引入变量。并且当我在查询流程流转时的mysql数据库日志时，会发现，其实varinst表是先于taskinst表操作的。
-------------------------------
今天，当我想了解流程变量的知识时，我看到了一个哥们的日志，非常精美，思路非常清晰，值得学习
----------------------------------
在对lemonOA的流程管理，和对activiti引擎本身学习和愈加熟悉之后，我想我应该要好好理一下，整个流程这块的代码结构了。
---------------------------------
在学习一个系统时，最好的方式可能是：画出这个系统的状态图，然后由状态图得到事件Event编排方式。
比如在学习进程时，进程的：就绪-启动-执行-阻塞-终止 等等。
比如在学习GUI编程时，事件的：鼠标类型事件-键盘类型事件-其他事件 等等。
事件 是状态改变之后的信号signal。
--------------------------------
周三下午周会汇报：
1. 我现在在设计请假流程；
2. 单单请假这一个流程的需求是比较清晰的；
3. 现在遇到的问题是：（1）由于考虑到后期可能需要进行数据库存库操作，所以需要在流程流转的环节添加新的接口，而且还要设计数据库结构；（2）在请假流程中，有一些自动化任务需求，如根据请假类型和请假天数，进行一些自动化的任务，这需要我们在系统中添加一个规则引擎。这是现在遇到的主要两个问题。
----------------------------------
在lemonOA中，定义了很多的listener，这些listener是如何发挥作用的?
一步一步追踪，我们可以看到代码最终还是作为processEngineConfiguration的配置属性，研究下activiti与spring的配置接口。这块知识属于spring与activiti的接口范畴，里面的字段属性不是很清楚。
-------------------------------------
我想了想，进日志系统查看一下不同listener的执行顺序应该比较好一点儿。正好可以摸一下这个OA的日志系统搭建情况。
--------------------------------------
系统还是过于庞大，我决定还是一行一行代码走一遍吧。
--------------------------------------
一直对lemonOA的变量管理搞不清楚。现在稍微有点概念，activiti的设置变量的方法是setVariables（ID, MAP）；
我想这样的话，lemonOA要么直接调用taskService进行setVarible，要么也是进行封装，然后lemonOA里果然是进行封装的。
--------------------------------------
在对lemonOA的流程管理模块的代码，大致过了一遍之后，对其大致有了这样的体会。
首先，按照这样的思路，如果根据功能是不是直接走activiti，可以将代码分为：扩展代码和调用代码。
其次，按照模块进行划分，可以分为：（1）modeler，建模器模块。（2）个人任务模块，相当于流程管理的前端。（3）流程管理的后台，对流程进行配置。（3）表单设计模块。
代码分布是这样的，分为注册式的代码，写在listener中。调用式的代码，写在controller中。代码中，有很多的接口，自然是为了好扩展。还写了很多的command对象，但是在我看来，这些command对象，似乎不大好，因为这里command只是一种回调函数而已，还不能够进行参数expression的解析。当然这也算command了。
--------------------------------
下一阶段，考虑如何配置drools引擎，并且实现表单和数据库的对接工作（主要是考虑重用的问题）。