各位高手:    我正在评估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开发经验的高手多多指导,先谢了^_^

解决方案 »

  1.   

    在B/S开发中,Web UI往往占据了大部分开发工作量,所以我们考虑采用WYSWYG的
    开发方式,具体就是采用开发工具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:日志
        因为研发工作不能“点到为止”,所以我会花一些时间做实践验证,验证这种开发
    模式能否完全满足上面的需求并提高开发生产率,存在哪些风险,当我们能确保这些都
    没有问题后,我们才能使用这种开发模式。
      

  2.   

    TO:
        rambostar() ( ) 信誉:94  兄
      这么多分咋就没人顶呢?
      现在想想,JSF还是不够成熟吧,有待大家继续努力呀!
      

  3.   

    楼上的兄弟,有没有msn啊,一起研究研究啊
      

  4.   

    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
      

  5.   

    Blog:http://ayufox.blogcn.com/
    有一篇关于与Spring的集成和一篇列表分页
      

  6.   

    rosifox(下着鱼的天)兄的经验还是非常丰富啊,学习!
      

  7.   

    总体框架用appfuse(jsf + spring + hibernate),但web层框架jsf的开发我试试sun java studio creator 2 update 1开发,大家有没有这方面的最佳实践?rosifox(下着鱼的天)兄有什么好建议没有?
      

  8.   

    sun java studio creator 2 update 1已经熟悉了
    Bea workshop studio 3.0也下载试用了
    jbuilder 2006也尝试了就不知道在实际的JSF项目开发中,这些工具究竟能提高多少开发生产力?
      

  9.   

    我很怀疑这东西能提高多少生产力,就我的经历来说,在JSF开发过程中,除了业务,最头疼
    的是JSF的错误定位,往往从其出错信息中得不到多少有用的东西,错误是不可避免的,
    如果在一个对JSF不熟的团队,在开始阶段,可能会是不低的代价,此外,我个人的感觉是JSF实现
    相对其它MVC框架而言本身比较复杂,其核心类太多,对其本身进行深入探索需要不少时间,
    当初为了JSF与Spring的集成,花了半天多的时间研究其源代码,也不过是对其最核心的几个类的关系有了个基本的了解,而相对而言,页面本身并不需要花费太多的时间,我的看法是,选择一种大家都比较熟悉的工具,不管是对现有的成员还是从以后成员变动的角度来所,都是一个比较稳妥的选择。
       题外话,在引入一种新的技术,还是应该谨慎加谨慎,至少在项目组中保持一个成员对该技术
    非常了解,在架构中,更忌讳对一知半解的东西随便使用,这一点在我前一个项目中的体会非常深刻,匆忙地引入Hibernate,糟糕的持久层架构,导致在项目后期的系统的效率简直就是噩梦。
       呵呵,其实本人也是一菜鸟(工作两年,两年半Java经历,也就刚好入门),比较喜欢研究Java方面的技术,比较自豪的是基础还是比较扎实。还请大家多多指教,有机会探讨
      

  10.   

    由于struts和webwork合并,所以,它们都不会有后续的版本,合并以后的规划是2个方向 ,Struts Action Framework和Struts Shale Framework,其中Struts Shale Framework相对独立,以JSF为中心, Struts Action Framework是基于webwork的。另一个原因是JSF是j2ee的标准,从长远来看也是发展趋势。大家可参考appfuse的jsf demo。
      

  11.   

    rosifox(下着鱼的天)兄说的有道理,这也是我一直在webwork、tapestry和jsf之间犹豫的原因,但sun java studio creator 2 update 1的开发方式确实非常有吸引力,rosifox(下着鱼的天)兄可以尝试用用它。
    对于新技术我们要多进行实践验证,但也不要太怀疑它的可行性。
    记得比尔盖茨说过:“vb能做什么,并不取决于vb,而取决于使用vb的这个人”
      

  12.   

    rambostar()兄,听说java studio creator 2 update 1是耗内存的,是不是啊?
      

  13.   

    另一个原因是JSF是j2ee的标准,从长远来看也是发展趋势。    这句话我保留意见,呵呵,就其复杂性来说,难保JSF不会是又一个EJB2。不过也正如我上面说的,JSF是标准,附加带来的好处是大量丰富的组件,这一点也是JSF最诱惑我的地方,当然,代价也是不低的,因为特殊需求的需要开发JSF组件的复杂性
      

  14.   

    另一方面,我仅从我自己的使用类似组件的体验来发表我的观点,这点确实不够
    严谨科学。其实也就事实确实应如你的目的一样,以严肃的态度应对,多加验证。
    我们现在项目组引入JSF的做法可能可以给你一些参考价值,在做完可行性分析之后,
    我们首先是在一个小项目中体验JSF,一方面熟悉该技术,体会其优点缺点,另一方面
    经过实战,对JSF可以做更科学的结论。我想,这个也可以应用到其它的技术和工具
    上。
        题外话,sun java studio creator 2 我是应该去尝试它,感受一下,事实上我也是
    比较喜欢尝试一些新鲜的事物。不过我自己的感觉来说,工具只是工具,最重要的是
    要趁手,我现在的开发环境都是自己选择的各种工具的组合,
    Eclipse + Ant + Xml编辑器 + JBoss启动插件(自己写的),当然,仅仅是个人的
    感受,各有所好,对别人没什么参考价值
      

  15.   

    工具当然仅仅是工具,但不可否认,工具确实能大幅度的提高开发生产力,想想如果不用vb或delphi,而用editplus去做相同的事情,将会怎么样。其实,tapestry也是非常好的,可惜没有好的工具支持。
    另外,说句实话,rosifox(下着鱼的天)说的很有道理,特别对于大型项目更是如此。
      

  16.   

    to mrdangdong():java studio creator 2 update 1是要求机器的配置高点,不然非常慢。
    我把java studio creator 2 update 1的例子及教程都实践了一遍,这个工具真的非常有前途!
      

  17.   

    我在广州工作,LZ在哪工作?
    能否留你的Email,有机会向你请教?
    我的Email是[email protected]
      

  18.   

    楼上的兄弟:我在深圳,我的mail是[email protected],多联系,多交流。(问一句,兄弟是否有意来深圳发展)
      

  19.   

    :) 半年后可能会有新的计划,现在都还很难讲,呵呵
    (小声问一声,按我这水平,才深圳能拿多少钞?我的BLOG:http://ayufox.blogcn.com/)
      

  20.   

    to rosifox(下着鱼的天)兄,半年时间我可等不起,其实只要你有实力,价钱都好谈,当然这些事情我们最好通过邮件联系,因为这里是谈技术的地方!^_^
      

  21.   

    建议采用成熟的Struts+Spring+ibatis
      

  22.   

    Struts成熟是够成熟,用户群也挺大的,资料更是其他框架所无法比拟的全,
    但是,以下缺点实在另人恶心:
    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的集成方式极其让人鄙视
      

  23.   

    说到这里,想起维护完一个JSF项目之后自己的体会:
    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就不抱太大的好感。
      

  24.   

    本人也比较推崇JSF,但在目前标签库不是很全,如果自己写的话是不小的工作量
      

  25.   

    稍微用了一下,有以下疑问:
    1.与第三方工具的配合情况:譬如与版本控制工具(SVN)的配合,与其它应用服务器的配合
    2.对第三方JSF组件的支持情况:是否可以将第三方JSF组件导入以支持拖拽式开发
    3.太多工具自动生成的文件,以及部分类与SUN的API的耦合,会不会对维护造成负担
    另外,作为一个Eclipse的使用者,我比较关心如下常用的功能:
    1.代码搜索功能:是否支持获得一个类/接口的继承结构视图
    2.在IDE中是否支持以调试方式运行应用服务器
    3.功能扩展:是否基于插件的结构?
    4.自动纠错
    5.重构功能:包重命名是不是有问题啊?
    6.源码阅读
    7.对JUnit的支持
      

  26.   

    Struts成熟是够成熟,用户群也挺大的,资料更是其他框架所无法比拟的全,
    但是,以下缺点实在另人恶心:
    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管理比较好。
      

  27.   

    4.状态信息保持:
    由于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框架,是不应该苛求过多
      

  28.   

    关于struts框架,架构确实有一定问题,但是大量文档和经验可以弥补其本身的不足。
    其实我现在也使用webwork,并且更看好下一个版本合并webwork后的struts,而不是JSF,
    这个可能和我不太喜欢在IDE里面拉控件编程有关,也可能是我JSF了解太少。关于ThreadLocal,比较典型的应用是HibernateUtil,spring的事务控制,acegi的filter.结合工具类,AOP或者filter这样模式的使用,我认为确实算是比较优美的,不算得丑陋。
      

  29.   

    另一给分点,高手门继续发表高见!http://community.csdn.net/Expert/topic/4897/4897540.xml?temp=.6549646
      

  30.   

    呵呵, 跟我们项目中使用的技术一样.j关注一下。
    不过sf资料太少,有问题不太好解决。相信这个问题是个时间问题。