1. userIndex里面，$ctx是在哪里定义的？
就是request.context
2. 增加新的包后，扫描配置修改
1) spring-context.xml文件中，扫描非@controller注解，需要添加路径
<context:component-scan base-package="com.thinkgem.jeesite,com.neusoft.bigdata">
<context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
</context:component-scan>
2）spring-context.xml文件中，MyBatis的类entity/Dao类扫描
<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
<property name="typeAliasesPackage" value="com.thinkgem.jeesite,com.neusoft.bigdata"/>
... ...
</bean>
3）spring-mvc.xml文件中扫描@controller所需要添加的路径
<context:component-scan base-package="com.thinkgem.jeesite,com.neusoft.bigdata" use-default-filters="false">
<context:include-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
</context:component-scan>
3. Jeesite的权限控制
为什么cms的菜单配置其实没什么权限都没有，但是后台代码却又有@RequiresPermissions("cms:site:view")?
其实cms的菜单项没有权限是第一层没有权限，真正点开看到下级节点是view、edit、delete等操作定义，都是有明确权限定义的。
Jeesite的权限控制思路是这样的，首先是给menu赋权限，然后把menu赋给角色，角色包含用户；这样用户就具备了menu权限；然后后台的controller通过@RequestPermission来设定调用该方法的权限；只要你的用户权限中（menu）有了该权限，也就可以调用方法；
Jeesite的权限思路是：
1）菜单来实现权限定义；菜单有可见菜单和隐藏菜单，隐藏菜单就是那种纯权限意义，比如XX功能的编辑，删除等。
2）通过用户和菜单绑定实现授权；
3）controller的@RequestPermission来指定请求权限；
权限（认证以及授权逻辑）都是在com.thinkgem.jeesite.modules.sys.security.SystemAuthorizingRealm里面实现的；加载权限的逻辑首先把用户的被赋予的菜单（权限）便利出来放到用户的权限字典中去；在授权的过程中，将会判断操作所需要的权限（由@RequestPermission中定义）是否在用户的permissons字段中有定义；有则可以继续操作，没有则不能继续操作。
4.菜单的设计
关于菜单的设定，一定是大于两级的（至少三级，否则无法显示左侧的子菜单），第一个级别是顶部菜单（和“我的面板”，“在线办公”等平级）；第二个界别是左侧菜单的父级目录（至少有个子菜单），第三级别是左侧父级目录的下级目录/ 叶子节点。
5. jeesite消息提示
发现提交后，“正在提交，请稍等”的字样一直在转圈，跳转到了List页面也没有消失，而且成功提示也没有。
后来发现原来需要在List页面增加一句话：
<sys:message content="${message}" />
这句话一方面展示了成功提示，另一方面可以把“正在提交”的字样给冲跑。
但是注意，需要在提交处理的函数中增加一个RedirectAttributes，用于存放在redirect过程中存放的变量；这里用于存放成功提示。
6. spring的配置文件
在实现分页的时候，想要使用缓存来保存查询结构再来进行分页（hive的分页只能这样来处理）。在使用Jeesite内部缓存（EchCache）的时候，在spring的文件中看到了
<!-- 缓存配置 -->
<bean id="cacheManager" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">
<property name="configLocation" value="classpath:${ehcache.configFile}" />
</bean>
是的，${ehcache.configFile}是什么鬼，配置项，但是配置项在哪里？
原来在这里：
<context:property-placeholder ignore-unresolvable="true" location="classpath:jeesite.properties" />
但是为什么点击下一页的时候还是定位pageNo为0？
1）这是因为jeesite提供了一个分页拦截器PaginationInterceptor；这个分页拦截器将会填充count值；
2）有了这个count值，还不够，在Page的setList函数中，将会调用一个函数initialize()，这个函数将会根据count来计算last等一系列值；这一系列值将会在渲染HTML页面的时候起到设定参数的作用。
分页的水，还是很深的。
7. 分页
前台页面有一个脚本函数，叫做page（默认的名称，如果是多个分页，用到不同的逻辑，需要设置Page对象funcName属性）；
function page(n,s){
$("#pageNo").val(n);
$("#pageSize").val(s);
$("#pageForm").submit();
return false;
}
这里面的n参数是关键，页面在渲染的时候，会把前一页的调用脚本参数设置为当前页的前一个索引；会把后一个页的脚本参数设置为当前页的后一个索引；
提交（commit）之后，到了controller，controller将会从request对象中取出pageNo以及pageSize的值填充到后台构造的新的Page对象，然后到后台数据库中取出对应的数据集，这里的分页的sql是自动生成的sql中已经生成好的，你只需要调用一个findList函数即可；
Page的构造函数中有个HttpServletRequest对象比较好理解，用于获取参数，但是还有一个HttpServletResponse对象，这个response对象用于在cookie中存放对象，这样就可以在前台的cookie中存放这些内容；从代码逻辑来看，是当request中无法获取这些信息的时候，将会从cookie中获取。
因为page需要response对象，所以处理分页的controller的参数中是需要包含response的。
public String execSql(SqlExeInfo info, Model model, HttpServletRequest request, HttpServletResponse response) { ... ... }
然后page对象将会生成渲染html，前面讲到的前一页，后一页的绑定脚本以及参数的设置都是在page中来做的；另外，通过访问数据库获取的分页数据集也是保留在Page对象中。
controller的返回也是把填充好的page对象放到model的attribute中。
页面渲染的时候会把分页部分html生成好；展示出来。然后点击、输入分页信息将会跳转到对应的controller进行处理... ...
8.代码生成需要指定至少一个更新列
今天要自动生成SqlHistory，但是生成总是失败；后来跟踪了一下代码；才发现原来是因为Jeesite是要求你至少要有一列是可以“更新”的；因为在生成dao.xml的时候，他会去读取更新的字段，如果没有那么就会返回一个异常；这个地方也是它的一个BUG吧。
不过代码生成这部分使用的是freemarker来搞的；有时间可以研究一下。
9.Could not resolve type alias 'SqlHistory'
Caused by: org.apache.ibatis.builder.BuilderException: Error resolving class. Cause: org.apache.ibatis.type.TypeException: Could not resolve type alias 'SqlHistory'. Cause: java.lang.ClassNotFoundException: Cannot find class: SqlHistory
Jeesite需要在spring-context.xml中节点“sqlSessionFactory”以及“mapperScannerConfigurer”节点，增加项目的节点扫描（默认只有jeesite的）
10.未解配置
<filter>
<filter-name>httpMethodFilter</filter-name>
<filter-class>org.springframework.web.filter.HiddenHttpMethodFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>httpMethodFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
RESTful的filter要放在最后面，如果放在encodingFilter的前面将会导致乱码问题。这是为什么？
10.Jeesite字段变更，SQL文件重新生成处理
如果表的字段发生了变化，这个时候注意需要把业务表配置以及生成方案都删掉，这是因为表的配置一旦配置死了字段名称和entity的对应关系，也就没有了修改的余地了（表字段是固定死的，不再会和物理表进行同步）。
11. 缓存
发现总是爆Ehcache序列化异常，因为HiveConnection；但是诡异的是我根本就没有把hive session放置到Ehcache中啊。
没事，你没放，自然有人放；其实HttpSession被Jessite框架管理的是会被不断序列化的，因为HiveConnection没有实现ISerializalbe接口，所以序列化失败。
我在读源码的时候，发现还有一个MemerySessionDao挺好，没有Ehcache那么重，还序列化到硬盘中。但是为什么spring初始化的时候报错？我想了一下，觉得可能是因为MemorySessionDAO所在的包并不是Spring监控的路径；于是我在CacheSessionDAO同级包体下添加了一个类，继承自MemeryCacheDAO；但是总是报错，Login在反射初始化SessionDAO的时候并没有找到一个类继承自SessionDAO；这就很奇怪了，因为我翻看了源码MemeryDAO是实现了这个SessionDAO；
但是其实是此SessionDAO非彼SessionDAO。
明白了；于是我又继承了这个SessionDAO，实现了两个函数，这次才成功。
12. 自动生成用户树
因为调用的时候采用的是直接new了一个类，而没有采用autowired的方式导致了，内部的类实例化有问题。