|
精华帖 (5) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
最后更新时间：2008-03-14
wufan0023 写道 linliangyi2007 写道 个人觉得让看代码的人易读懂，易维护是很重要的，尽量使用大家都知道的技术！
一个人的兴趣作品爱用啥用啥！——我们的宗旨是，不求最好，但求最BT！咔咔！ 同意这个观点。 现在开发最重要的是团队开发和维护。无论什么技术都一样，技术这东西现在没有什么决定的事情。 开始的时候我也是觉得JSF如何如何，现在长期做下来就发现，用户的需求是不可能封装起来的，哪怕看起来一模一样，但是还是要单独实现，如果合并起来你就等着吃苦吧。。。（现实经历）。所以复用这事情还是有待商榷的。 粒度问题。 |
| 返回顶楼 | |
|
最后更新时间：2008-03-14
Joo 写道 JSF不但不会让你忘记request的生命周期,还会要你记住JSF的生命周期的六个阶段 每个阶段的层层关系,事件,验证... 总之我觉得为了一点点swing-like的事件触发而包装一个更大的炸弹真的很辛苦.我用JSF已经作了三个项目了,说实话很累.JSF在很多方面不能满足需要,只能HTML+JS+JSF的混在一起弄,但是公司里面又要求用jsf,没有办法.如果是我自己,可能更倾向于用单纯的jsp+serlvert,或者ROR 因为很多开发者在进行jsf开发的过程中遇到了很多特殊性很强的表现层需求，由于jsf规范的实践性不好，所以导致必须使用一些基于jsf组件的策略或者直接混合常用的request方式来解决问题，在这一点上我肯定是承认的。本来这些问题是可以通过增强的组件实现来完成的，但是组件开发的复杂度往往又约束了这种行为，导致了很多不佳的实现方式，甚至是痛苦的寻找解决方法，往往觉得很简单的事情，放到jsf怎么就这么难。 这也对于jsf组件的认识就有了很高的要求，需要了解组件的外部接口，有很多复杂的表现层交互可以通过调用jsf组件外部接口来更改组件状态的策略实现的，那么这就需要了解jsf的生命周期和组件的运作方式，这也就是你所说的层层关系都需要了解。所以也是我认识的一个开发实践问题：需要一个或几个对jsf把握比较深的横切式开发者。 但是我的这个观点详细说起来，就是jsf留给开发者的不是要了解request的整个生命周期，而是关注业务模型，业务模型作为jsf绑定的backing bean，已经把生命周期中的数据和操作都进行了良好的定义，你不需要知道这个bean的数据是怎么从request来的，你也不需要知道你调用的操作是在request中什么时候执行的，而是知道他监听了一个事件。对于大部分的情况都可以使用，那么如果在有横切式开发领导者对于特殊情况的优雅处理后，那么留给大部分开发人员就可以高度关注业务模型怎么和展现组件进行映像，怎么验证，怎么进行类型转换。这只是一个好的开发实践，但是每个开发组的情况不同。 忘记request声明周期，并不等开发者就一定不要懂得jsf生命周期，对于jsf框架了解越多越可以摆脱项目在开发中的种种技术难题。但是开发模式的初衷就是要忘记基于请求这种无状态所带来的种种额外要求。给项目带来一个较纯粹的业务对象交互。这种方式肯定是利于维护，重用，积累！ |
| 返回顶楼 | |
|
最后更新时间：2008-03-14
Apusic OperaMasks是基于JSF规范的一个开源框架，并且提供丰富的JSF组件。在AOM2.0中编写一个自定义的JSF组件将变得非常简单。AOM2.0中对JSF状态的处理也显得比较的优雅，传统JSF是在JSF生命周期的Restore View阶段恢复组件树的状态（或者构造一棵组件树），而在AOM2.0中采用Facelets技术作为描述JSF组件的载体，可以在JSF的Restore View阶段之前，通过这个载体，构造一棵JSF组件树（当然这需要设置一个参数）。而这样做的好处，JSF只保留了组件树在运行期产生的状态信息，其他信息则可以通过这个Facelets载体来获得，这样就大大减少JSF组件的状态信息在客户端和服务器端之间的传递。
可以到OperaMasks官方网站（www.operamasks.org）上详细了解AOM，同时AOM2.0M2即将发布，到时候可以在OperaMasks官方网站上下载。在使用AOM开发过程中结合可视化开发工具Apusic Studio，将大大提升开发效率。Apusic Studio 5.1 M5也即将发布，到时候可在www.apusic.com上下载。 |
| 返回顶楼 | |
|
最后更新时间：2008-03-14
xxjhappy 写道 Apusic OperaMasks是基于JSF规范的一个开源框架，并且提供丰富的JSF组件。在AOM2.0中编写一个自定义的JSF组件将变得非常简单。AOM2.0中对JSF状态的处理也显得比较的优雅，传统JSF是在JSF生命周期的Restore View阶段恢复组件树的状态（或者构造一棵组件树），而在AOM2.0中采用Facelets技术作为描述JSF组件的载体，可以在JSF的Restore View阶段之前，通过这个载体，构造一棵JSF组件树（当然这需要设置一个参数）。而这样做的好处，JSF只保留了组件树在运行期产生的状态信息，其他信息则可以通过这个Facelets载体来获得，这样就大大减少JSF组件的状态信息在客户端和服务器端之间的传递。
可以到OperaMasks官方网站（www.operamasks.org）上详细了解AOM，同时AOM2.0M2即将发布，到时候可以在OperaMasks官方网站上下载。在使用AOM开发过程中结合可视化开发工具Apusic Studio，将大大提升开发效率。Apusic Studio 5.1 M5也即将发布，到时候可在www.apusic.com上下载。 托儿吧~~~ |
| 返回顶楼 | |
|
最后更新时间：2008-03-15
Apusic OperaMasks 技术到很先进，就是推销手段太俗了！
顺便引用一下袁红岗的话：它(jsf)并不是解决开发问题的，它实际上是一种思想，是一种思想框架。在这样的框架下，能够更容易的适应各种各样的需求。这样就有了顽强的生命力，不管技术怎么变，都能够适应这种变化。所以它生命周期是无限的。 |
| 返回顶楼 | |
|
最后更新时间：2008-03-16
光从这个帖子的热度来说,jsf是有价值的,还有很多是为人不知,或者说很少人能把这个东西说明白.
sun通常是会出一些很有前瞻性的东西的,需要等到n久以后才为人所知. 就web.xml一个配置文件,仔细看看,spring的配置文件.比较一下两者有多大区别. applet和flash,以及activex. 还有Java web starter 和 现在的RIA. 虽然对jsf了解不多,除了本身学习取消有点陡之外,可能跟水土也关系. 答标题:对于一个项目来说 jsf带来的项目成本会高一些,但是对于持久的项目来说,jsf会帮助你降低成本. 因为它自身就是一个非常注重积累的框架. 而jsp+js,再多的项目过来也很难积累出可供复用的东西. |
| 返回顶楼 | |
|
最后更新时间：2008-03-16
armorking 写道 dengyin2000 写道 JSF优雅？ 比tapestry wicket差多了。 他那个自定义组件还要写对应的tag。 JSF也就最多算半个组件框架。
不是搞Seam， 鬼才会用JSF. 此话差矣 我已经在IBM的RWD环境、JSF+Spring+iBATIS的架构下作了两年多了 除了一开始不明白JSF的生命周期的时候吃了些药之外 现在用得蛮爽的 所谓风险、复杂度之类的，都是因为不了解才造成的 我倒不是说JSF就比这个那个的好 我的理解是:如果什么框架都只是浅尝辄止的话， 那么无论用什么框架都避免不了“风险、复杂度” 赞同。不管什么框架，只要用熟了就好。 |
| 返回顶楼 | |
|
最后更新时间：2008-03-16
项目管理者更难在时间,成本与质量上找到平衡点,
项目的技术实现会随着需求的增加而显的束手束脚. 项目难于进展, 长时间没有个交付物的时候, 项目组的人员也会士气低落 . 由于项目的复杂度节节攀高, 公司内的其它员工谁也不敢轻易进入...死项目就是这样产生的 JSF组件开发的不好的应变性, 与带来的好处, 我觉得并不成正比例. 现在正在用Oracle ADFaces做一个项目，体会和楼主差不多！！！ |
| 返回顶楼 | |
|
最后更新时间：2008-03-16
从技术上看，JSF是一个不错的框架规范，它欠缺的是一个强有力的，能够统一JSF世界的框架实现。如果有了这个框架实现，那么我们就可以在此之上发展JSF，简化JSF的扩展组件实现。而如今，我们只能依靠自己的力量
我已经在JSF上工作了一段时间，也已经在整合JSF，Facelets, Ajax,Spring，Spring webflow。过程中，也感觉JSF，Facelets的一些缺陷，但都需要自己花很多时间去实践，解决，的确是有点疲。 |
| 返回顶楼 | |
|
最后更新时间：2008-03-18
JSF 的思想很不错，但是还需要很长的时间来完善和添加辅料。
就像以前应用程序开发中使用的第三方组件一样！！ 需要有更加实用和功能强大的组件出现，来方便设计和开发！ 上面提到的横向的观点是很不错， 但是一般规模的公司至多只能作为开发的补充和提供技术支持，而没有足够的精力来解决更多问题！！ 我相信JSF的未来会很不错！ |
| 返回顶楼 | |
