现在的代码生成器生成的代码文件都会[color=red][b]自动插出[/b][/color]在我们的项目中,为何不提供一个将生成的文件生成在硬盘某个目录下,再由我们[color=red][b]手工copy[/b][/color]回来工作区?
这样可以避免开发人员需要考虑文件会不会被[color=red][b]覆盖[/b][/color]的问题.并且手工的动作很快,也不容易出错.
本人编写了的一个基于数据库的代码生成器,就是要解决上面提到的问题,可以生成Hibernate Model,Dao,Manager,Struts/Struts2 Action,JSP页面(增删改查及列表页面,表单验证),以下为代码生成器相关特性
[list]
[*]以application方式运行生成器,代码即是配置.
[*]将文件系统的目录名称及文件名称作为生成器的一部分,模板文件的的名称与目录名称可以直接引用相关变量,如[color=red]${basepackage}/${className}.java[/color] (${className}=Blog,则会生成Blog.java)
[*]以@testExpression结尾的模板文件为有条件忽略,如果testExpression的值在数据模型为true则生成该文件,生成的文件不会包含@testExpression,反之则不生成该文件(应用场景:用于在是否要生成hibernate联合主建的文件中)
[*]支持文件插入操作,如模板输出生成的地方已经有该同名的文件存在,并且文件中有包含"webapp-generator-insert-location"标记,则模板生成的内容会插入在该标记之后该特性对如生成的spring配置内容插入spring配置文件十分有用
[/list]
生成器入口
这里是上一篇[搞不明白],被移至入门区了
[url=http://www.iteye.com/topic/212867][搞不明白]直接在Action中返回forward不好么[/url]
搞完了[搞不明白],会发布一个应用开发框架,提供类似rails的基于url确定action访问的零配置快速编程,自带一个代码生成器,已经完成的组合基于struts+spring+hibernate,struts2+spring+hibernate.
这样可以避免开发人员需要考虑文件会不会被[color=red][b]覆盖[/b][/color]的问题.并且手工的动作很快,也不容易出错.
本人编写了的一个基于数据库的代码生成器,就是要解决上面提到的问题,可以生成Hibernate Model,Dao,Manager,Struts/Struts2 Action,JSP页面(增删改查及列表页面,表单验证),以下为代码生成器相关特性
[list]
[*]以application方式运行生成器,代码即是配置.
[*]将文件系统的目录名称及文件名称作为生成器的一部分,模板文件的的名称与目录名称可以直接引用相关变量,如[color=red]${basepackage}/${className}.java[/color] (${className}=Blog,则会生成Blog.java)
[*]以@testExpression结尾的模板文件为有条件忽略,如果testExpression的值在数据模型为true则生成该文件,生成的文件不会包含@testExpression,反之则不生成该文件(应用场景:用于在是否要生成hibernate联合主建的文件中)
[*]支持文件插入操作,如模板输出生成的地方已经有该同名的文件存在,并且文件中有包含"webapp-generator-insert-location"标记,则模板生成的内容会插入在该标记之后该特性对如生成的spring配置内容插入spring配置文件十分有用
[/list]
生成器入口
public static void main(String[] args) throws Exception {
Generator g = new Generator();
g.clean();
g.generateTable("blog");
// g.generateAllTable();
}
这里是上一篇[搞不明白],被移至入门区了
[url=http://www.iteye.com/topic/212867][搞不明白]直接在Action中返回forward不好么[/url]
搞完了[搞不明白],会发布一个应用开发框架,提供类似rails的基于url确定action访问的零配置快速编程,自带一个代码生成器,已经完成的组合基于struts+spring+hibernate,struts2+spring+hibernate.