关于Struts2的一些记录

一、Struts2的Convention零配置的注意点：

        1）其实真正的零配置，是遵循”约定大于配置的原则“。在开发时我们按照“某种规则”来建立目录和命名文件，而Struts2在运行时则根据规则去匹配。但是看到网上很多资料感觉大家实际上在某种程度上有点误解“零配置”的本质含义。很多网友说的所谓的“零配置”实际上是把原本应该放在XML中的配置改用注解去配置了，而且同时这些文章还顺便介绍了Spring MVC零配置的优越性。我个人觉得Spring只是把原本在XML的配置换成了注解，而没有真正意义上实现“零配置”。而且这种注解的配置方式导致原本应该“集中放置”的配置“分散”到每个类里去了，这样反而更加不容易管理。所以，在用Struts的零配置时尽量做到也不要用注解去配置。

        2）零配置也有一定的使用范围。比如说，我们基于“组件”的方式来开发程序，每个“组件”一般尽量做无论是源码管理和开发，还是运行，组件都尽量能“独立”，而不是过于依赖“组件”之外的配置（比如，我们通常只有一个配置文件，而且这个配置文件是放在“组件”之外，如果把“零配置”的一些参数放在该文件中，则如果这个参数被不小心修改了，则会影响到“组件”的运行）。这个时候就可以使用注解或者XML的配置方式。当然了，注解的方式其实多少还是要受到Struts2总配置文件的影响的。而XML的方式，则需要基于Struts2的插件规则进行开发或者是对Struts2进行扩展。

        3）网上的有些说法是存在问题的，比如很多网友说：以“Action”结尾的Action类，比如UserAction是会被Convention识别的。但是经过本人多次试验，得到一个结论是：如果我们自己写的Action不继承ActionSupport这个类，或者不实现Action接口，同时这个类没有execute方法时，这个类是不会被Convention插件识别的。也就是说如果我们不继承或者实现Struts2的任何类和接口，即使类名是以“Action”结尾的，也不会被识别。本人现在还想不通为什么Convention插件要这样设计，将来有时间去研究下Convention插件的源码以后再下结论吧。

二、对于Struts插件的原理初探：

        之前发现网上关于Struts插件的原理和规则资料极少，这次由于一些框架设计的需要对这些插件进行了研究。得到了一些小总结，当然了，不一定完全正确，将来继续完善，姑且先记下来存档。

       1）所有的插件都有一个struts-plugin.xml的文件，而且放在插件jar包的根目录下，所有关于该插件的配置都在这个插件配置文件里有默认配置。

       2）这些插件可以被覆盖和替换（利用Struts加载和解析配置文件的顺序的方式），这样增加了插件的灵活性和可扩展性，就像面向对象中的“继承性”和“多态性”，这是非常了不起的思想。

       2）插件运行时需要依赖的一些对象，可以使用<bean>标签进行配置，则该对象会由Struts2自己的IOC容器来管理，并可以将此对象注入到使用对象中。而不用配置到外边容易被人无意间修改的Struts配置文件中。这样保持了插件的“独立性”和“完整性”。

       3）插件启动时可能有前后依赖关系，所有有一个order属性。

       4）如果插件中不但有后台的java程序和前台的css,js等静态文件，则采用freemarker的include标签，直接使用静态文件内容融合到页面中去（就类似直接在页面上写的js或者是CSS）。所以struts2插件现在支持的页面很样式什么的很有限，可以查看零配置查看器config-browser的一些静态文件和页面文件就清楚了。当然了，对于静态文件的处理可以借鉴DWR的处理方式，js等静态文件同样可以放在jar包里，也许将来struts2会改进这些。

       这些只是简单看了下总结的东西，这些思路在某些基于“组件化”开发的项目或者平台中可以借鉴下。