各位高手: 我正在评估sun java studio creator 2 update 1进行实际项目开发的可行性,它的可视化拖曳jsf组件开发方式确实非常有吸引力,有点.net的意思了。
另外,我以前也用appfuse(jsf + spring + hibernate)做过项目,所以,我想用appfuse + sun java studio creator 2 update 1进行新项目的开发,不知道大家有没有这方面的经验,一起探讨探讨!
请有appfuse(jsf + spring + hibernate)开发经验或sun java studio creator 2 update 1开发经验的高手多多指导,先谢了^_^
另外,我以前也用appfuse(jsf + spring + hibernate)做过项目,所以,我想用appfuse + sun java studio creator 2 update 1进行新项目的开发,不知道大家有没有这方面的经验,一起探讨探讨!
请有appfuse(jsf + spring + hibernate)开发经验或sun java studio creator 2 update 1开发经验的高手多多指导,先谢了^_^
开发方式,具体就是采用开发工具sun java studio creator 2 update 1进行可视化的
拖曳JSF组件方式进行开发,由于是新技术,开发思维和方式有所不同,所以我们必须
进行实践验证,客观的评估,下面是我当前正在进行的实践验证:团队方面:
1:是否适合一定规模的团队开发,怎么进行风格统一的团队开发?
2:团队怎么进行分工?
3:怎么进行分模块的迭代开发?
4:怎么进行日构建?具体技术实现细节方面:
1:项目模板及布局,统一的页面风格及修改
2:国际化
3:客户端校验
4:报表及打印
5:自定义的jsf组件开发及第三方jsf组件使用
6:AJAX组件使用
7:重复提交及异常处理
8:分页及服务端的排序
9:兼容及扩展
10:应用服务器的集成,单步跟踪及调试
11:与spring集成
12:安全
13:事务处理
14:cache
15:日志
因为研发工作不能“点到为止”,所以我会花一些时间做实践验证,验证这种开发
模式能否完全满足上面的需求并提高开发生产率,存在哪些风险,当我们能确保这些都
没有问题后,我们才能使用这种开发模式。
rambostar() ( ) 信誉:94 兄
这么多分咋就没人顶呢?
现在想想,JSF还是不够成熟吧,有待大家继续努力呀!
1:项目模板及布局,统一的页面风格及修改
JSF可以与Tiles结合使用,不过实际开发并没有使用到,开发中主要框架使用frame
2:国际化
JSF对国际化的支持非常好,两个特点:多文件保存国际化信息,可以静态/动态设置语言
3:客户端校验
没有太好的支持,曾在网上搜到一个客户端验证的JSF组件,不过总的来说还是比较原始
5:自定义的jsf组件开发及第三方jsf组件使用
在网上有丰富的JSF组件,不过一旦需要自己开发,难度还是不少,而且调试比较麻烦
6:AJAX组件使用
在网上也有丰富的AJAX方面的JSF组件
8:分页及服务端的排序
网上有这方面的组件
11:与spring集成
增加Spring的支持非常简单,见我的Blog:
15:日志
与其它框架没什么区别另外,我的感觉是,WYSWYG对Java应用的开发的效率提高比较有限,更多的时候我宁愿
自定置一些模板,需要的时候复制过去再做裁减。JSF最大的好处在于其标准,附加带来的好处是网上有丰富的组件可以用,但一旦出现一些特殊的界面,开发简直就是噩梦,如果可以选择的化,我宁愿是WebWork + FreeMarker
有一篇关于与Spring的集成和一篇列表分页
Bea workshop studio 3.0也下载试用了
jbuilder 2006也尝试了就不知道在实际的JSF项目开发中,这些工具究竟能提高多少开发生产力?
的是JSF的错误定位,往往从其出错信息中得不到多少有用的东西,错误是不可避免的,
如果在一个对JSF不熟的团队,在开始阶段,可能会是不低的代价,此外,我个人的感觉是JSF实现
相对其它MVC框架而言本身比较复杂,其核心类太多,对其本身进行深入探索需要不少时间,
当初为了JSF与Spring的集成,花了半天多的时间研究其源代码,也不过是对其最核心的几个类的关系有了个基本的了解,而相对而言,页面本身并不需要花费太多的时间,我的看法是,选择一种大家都比较熟悉的工具,不管是对现有的成员还是从以后成员变动的角度来所,都是一个比较稳妥的选择。
题外话,在引入一种新的技术,还是应该谨慎加谨慎,至少在项目组中保持一个成员对该技术
非常了解,在架构中,更忌讳对一知半解的东西随便使用,这一点在我前一个项目中的体会非常深刻,匆忙地引入Hibernate,糟糕的持久层架构,导致在项目后期的系统的效率简直就是噩梦。
呵呵,其实本人也是一菜鸟(工作两年,两年半Java经历,也就刚好入门),比较喜欢研究Java方面的技术,比较自豪的是基础还是比较扎实。还请大家多多指教,有机会探讨
对于新技术我们要多进行实践验证,但也不要太怀疑它的可行性。
记得比尔盖茨说过:“vb能做什么,并不取决于vb,而取决于使用vb的这个人”
严谨科学。其实也就事实确实应如你的目的一样,以严肃的态度应对,多加验证。
我们现在项目组引入JSF的做法可能可以给你一些参考价值,在做完可行性分析之后,
我们首先是在一个小项目中体验JSF,一方面熟悉该技术,体会其优点缺点,另一方面
经过实战,对JSF可以做更科学的结论。我想,这个也可以应用到其它的技术和工具
上。
题外话,sun java studio creator 2 我是应该去尝试它,感受一下,事实上我也是
比较喜欢尝试一些新鲜的事物。不过我自己的感觉来说,工具只是工具,最重要的是
要趁手,我现在的开发环境都是自己选择的各种工具的组合,
Eclipse + Ant + Xml编辑器 + JBoss启动插件(自己写的),当然,仅仅是个人的
感受,各有所好,对别人没什么参考价值
另外,说句实话,rosifox(下着鱼的天)说的很有道理,特别对于大型项目更是如此。
我把java studio creator 2 update 1的例子及教程都实践了一遍,这个工具真的非常有前途!
能否留你的Email,有机会向你请教?
我的Email是[email protected]
(小声问一声,按我这水平,才深圳能拿多少钞?我的BLOG:http://ayufox.blogcn.com/)
但是,以下缺点实在另人恶心:
1.参数收集能力(ActionForm):StrutsAPI的侵入性
2.ServletAPI的侵入性,导致测试相对困难
相比而言SpringMVC限制了ServletAPI的使用,另一方面提供了ServletAPI的Mock对象以方便测试;而WebWork更是以与ServletAPI的分离而让人所乐道;JSF在大部分情况下也可以避免与ServletAPI的耦合
3.功能扩展:
通过对Action的扩展以提供多余化的功能,这点明显不如WebWork的Interceptor来地灵活
4.状态信息保持:
由于Action不是线程度安全,在进行Action功能扩展时,Action状态的传递不外乎两种方式:方法参数传递,ThreadLocal方式。哪一种都不会让人感觉满意,后者更不是一般的丑陋。
5.表现层仅支持JSP
6.与Spring的集成方式极其让人鄙视
1.尽量在Faces(或者叫Bean吧)类中避免与ServletAPI的耦合。在维护该项目中,看到多处
这样的代码:
HttpServletRequest request = (HttpServletRequest) FacesContext.getCurrentInstance().getExternalContext().getRequest();
QueryCondition sesionObject = (QueryCondition) request.getSession().getAttribute("condition");
事实上采用下面的方式就可以很干净地解决这个问题
<managed-bean>
<managed-bean-name>condition</managed-bean-name>
<managed-bean-class>....</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
<managed-bean>
<managed-bean-name>faces</managed-bean-name>
<managed-bean-class>...</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
<managed-property>
<property-name>condition</property-name>
<value>#{condition}</value>
</managed-property>
</managed-bean>
2.尽量在Faces类中减少JSF的API的使用。我对actionListener就不抱太大的好感。
1.与第三方工具的配合情况:譬如与版本控制工具(SVN)的配合,与其它应用服务器的配合
2.对第三方JSF组件的支持情况:是否可以将第三方JSF组件导入以支持拖拽式开发
3.太多工具自动生成的文件,以及部分类与SUN的API的耦合,会不会对维护造成负担
另外,作为一个Eclipse的使用者,我比较关心如下常用的功能:
1.代码搜索功能:是否支持获得一个类/接口的继承结构视图
2.在IDE中是否支持以调试方式运行应用服务器
3.功能扩展:是否基于插件的结构?
4.自动纠错
5.重构功能:包重命名是不是有问题啊?
6.源码阅读
7.对JUnit的支持
但是,以下缺点实在另人恶心:
1.参数收集能力(ActionForm):StrutsAPI的侵入性这个是个问题,struts和webwork合并后,这个问题得以解决。2.ServletAPI的侵入性,导致测试相对困难。
相比而言SpringMVC限制了ServletAPI的使用,另一方面提供了ServletAPI的Mock对象以方便测试;而WebWork更是以与ServletAPI的分离而让人所乐道;JSF在大部分情况下也可以避免与ServletAPI的耦合同意。3.功能扩展:
通过对Action的扩展以提供多余化的功能,这点明显不如WebWork的Interceptor来地灵活
同意4.状态信息保持:
由于Action不是线程度安全,在进行Action功能扩展时,Action状态的传递不外乎两种方式:方法参数传递,ThreadLocal方式。哪一种都不会让人感觉满意,后者更不是一般的丑陋。持保留意见,Action单实例和servlet类似,因为方法参数传递和ThreadLocal方式,极少出现线层问题,Spring里面大部分对象也会是单例的,你写的时候会出现线层问题么?
ThreadLocal方式我无论如何看不出其丑陋,Spring,Hibernate也大量使用ThreadLocal,这种方式对代码侵入性很少。5.表现层仅支持JSP
没看出来只支持JSP,velocity等不是一样可以跑得好好的。6.与Spring的集成方式极其让人鄙视
没看出来有什么好鄙视的,就是action交给spring管理麻烦点,一般struts得action不交给spring管理比较好。
由于Action不是线程度安全,在进行Action功能扩展时,Action状态的传递不外乎两种方式:方法参数传递,ThreadLocal方式。哪一种都不会让人感觉满意,后者更不是一般的丑陋。持保留意见,Action单实例和servlet类似,因为方法参数传递和ThreadLocal方式,极少出现线层问题,Spring里面大部分对象也会是单例的,你写的时候会出现线层问题么?
ThreadLocal方式我无论如何看不出其丑陋,Spring,Hibernate也大量使用ThreadLocal,这种方式对代码侵入性很少。“大量”使用?我对此表示怀疑,ThreadLocal出现问题极其调试,特别是在应用服务器中因为线程重用,对于ThreadLocal的信息在每次线程结束时候必须将其清除干净,否则可能就会造成问题,除非迫不得已,我的建议是,远离ThreadLocal。对你前部分说法同意,单例也有单例的好处,个人偏号5.表现层仅支持JSP
没看出来只支持JSP,velocity等不是一样可以跑得好好的。这点是我的错,没有调查清楚随便做出结论,不过似乎其对表现层的
支持没有Spring和WebWork那么丰富6.与Spring的集成方式极其让人鄙视
没看出来有什么好鄙视的,就是action交给spring管理麻烦点,一般struts得action不交给spring管理比较好。我指的是其实现,从这点也可以看出Struts的架构确实是有问题,当然,作为第一个MVC框架,是不应该苛求过多
其实我现在也使用webwork,并且更看好下一个版本合并webwork后的struts,而不是JSF,
这个可能和我不太喜欢在IDE里面拉控件编程有关,也可能是我JSF了解太少。关于ThreadLocal,比较典型的应用是HibernateUtil,spring的事务控制,acegi的filter.结合工具类,AOP或者filter这样模式的使用,我认为确实算是比较优美的,不算得丑陋。
不过sf资料太少,有问题不太好解决。相信这个问题是个时间问题。