|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2007-04-03
sorphi 写道 真的搞不懂界面代码生成方面非要可视化IDE不可呢？
Dreamwaver，生成的html垃圾代码非常之多，最多只是利用它生成一个大概，局部的手工编辑我更放心 tapestry/jsf，我觉得并不需要一个可视化的IDE来拖拽组件 swing/awt，所有IDE提供的可视化设计器根本就是鸡肋，需要么？ 纵观这些可视化IDE生成的代码，一句话：根本就不放心 难道做界面的时候，尤其微调一些效果的时候，要写完一断，然后在浏览器里刷新一下看效果，然后再切换回代码编辑器再改？ 具体WYSIWYG工具的需要程度要视界面复杂度而定，一个BLOG可能不需要，可是一个功能很复杂的，页面也挤了很多东西的门户，十分的需要。 |
| 返回顶楼 | |
|
发表时间：2007-04-03
robbin 写道 1、如果你硬要说编写JSP Tag进行view局部重用很方便，很好用，功能很强大，比freemarker的macro好，那就没什么可讨论的了。我也可以说我走路速度比人家开车还快，基本认知存在分歧，就没有办法讨论。
2、view的自动化测试是web开发当中非常重要的一个环节，这一点连Uncle Bob都在自己的博客连续撰文讨论，如果你觉得view测试根本不重要，或者代价太高，还是上面那句话，基本认知问题。 3、有兴趣不妨随便研究一下现在开源的多用户博客软件，博客模板的切换涉及到整套资源的切换，包括CSS，JS，image，模板文件等等。而且你可能也没有实际体会过能够动态切换layout带来的巨大好处，这个话题也没有什么可说的。如果你觉得JSP Tag好，那就好吧。 1. JSF的Tag与Freemarker的macro没有可比性.二者的作用都不一样,你说要如何比较? JSF的以UI组件架构为核心,UI组件能够完成的功能并不是普通的Tag和Freemarker的macro可以 取代的. 比如数据绑定,状态维护,绑定事件,绑定验证等等 而且JSF是分离UI组件和Renderkit. Tag只是默认的RenderKit.换句话说,JSF并未绑定Taglib,你完全可以自己实现你要的RenderKit,但前提是非常清楚JSF内部的运做机制. 就因为一个Tag是默认的RenderKit就将JSF打死,实在是不敢苟同了. 2. View的Automatic Test可大可小,不知道robbin说的包括哪几块? 3. 这个问题方案有很多,不必要死报着Template着不放.况且不同的应用对样式切换的要求也不同. 最近有很多Opensource的开源组织都在整合JSF.最著名的要属Jboss Seam.Seam扩展了JSF,使Web开发应用开发更加简化. 这也正说明了JSF良好的扩展性. 并不能否定模板框架的优势,比如应用在代码生成.但JSF并没有你想象中的这么差,相反提供了很多新的特性. 定性一个框架要从多方面考察! |
| 返回顶楼 | |
|
发表时间：2007-04-19
JSF本人在2个项目中用过，算是中规中矩吧。也就是说，没有厂商宣扬得那么好使，也不像Java许多反对同道说得那么难用。
JSF与ASP.NET在本质上是一致的，是力图用C/S的方式解决B/S的问题，即用事件驱动模拟请求驱动。这样一来，对于规范化高的页面自然是提高了开发效率，但灵活性高的页面却又难以实现了。二者的差别在于JSF暂且没有达到ASP.NET的高度和成熟。 习惯了C/S事件驱动的程序员自然比较喜爱JSF和ASP.NET之类的东西；而习惯了B/S请求驱动的程序员自然偏爱Struts、Webwork、Spring MVC之类的框架。有些页面用事件驱动来得快，有些页面则是请求驱动方便，有些页面反而是传统的ASP、PHP所擅长。这正是各种技术存在发展的根本原因。 总之，把各自喜爱的技术发挥到极致才是最重要的。 |
| 返回顶楼 | |
|
发表时间：2007-05-09
Tapestry和Wicket根本就不需要专门的IDE啊
Tapestry用的不多，不说什么 象原来在公司使用Wicket开发的时候，美工只管做页面 拿过来以后，只要手工加一个wicket:id (在wicket0.9版本中更省事，只要写上id="wicket-XXX"即可)。 需要一个IDE吗? .Net有一个IDE，除了使用Tag是一个原因以外,就是它非常的全面，如DataSource等，所以做表格的时候，可以预览，这才是根本原因。 |
| 返回顶楼 | |
|
发表时间：2007-05-09
wl95421 写道 Tapestry和Wicket根本就不需要专门的IDE啊
当设计与开发有效分离之后，有多少程序员在做美工的活？有必要使用IDE来实现一个像DW这样的功能么？ |
| 返回顶楼 | |
|
发表时间：2007-05-09
rainlife 写道 wl95421 写道 Tapestry和Wicket根本就不需要专门的IDE啊
当设计与开发有效分离之后，有多少程序员在做美工的活？有必要使用IDE来实现一个像DW这样的功能么？ 基本上，美工做完的html页面程序员可以直接使用。 程序员开发以后的html模板，如果要做页面修改的时候，美工也可以直接修改，而且美工修改之后可以直接运行。从这点来说，Tapestry对IDE没有太大的要求。做页面直接可以使用DW。 Tapestry的缺点（同时也可能是优点）就是开发人员自由一个，而不是一个团队或者一个组织。在市场推广方面肯定比不上其他的框架。 Tapestry4.0.2到Tapestry5.0做了一个跨越性的发展。造成了没有向下兼容。这在技术上来说是个好事，因为可以使用更优异的技术框架。但是在市场上又有不利的地方。这样会造成很多之前的技术积累都白费了。所以去年下半年开始Tapestry的使用率开始下降就是这个原因。 |
| 返回顶楼 | |
|
发表时间：2007-05-09
lgx522 写道 JSF本人在2个项目中用过，算是中规中矩吧。也就是说，没有厂商宣扬得那么好使，也不像Java许多反对同道说得那么难用。
JSF与ASP.NET在本质上是一致的，是力图用C/S的方式解决B/S的问题，即用事件驱动模拟请求驱动。这样一来，对于规范化高的页面自然是提高了开发效率，但灵活性高的页面却又难以实现了。二者的差别在于JSF暂且没有达到ASP.NET的高度和成熟。 习惯了C/S事件驱动的程序员自然比较喜爱JSF和ASP.NET之类的东西；而习惯了B/S请求驱动的程序员自然偏爱Struts、Webwork、Spring MVC之类的框架。有些页面用事件驱动来得快，有些页面则是请求驱动方便，有些页面反而是传统的ASP、PHP所擅长。这正是各种技术存在发展的根本原因。 总之，把各自喜爱的技术发挥到极致才是最重要的。 页面用事件驱动并不神秘。 Struts、Webwork、Spring MVC都可以用js或者ajax来实现事件驱动。只不过需要自己写js脚本而已。 jsf和tapestry的事件只不过是动态生产js脚本来实现事件机制的。如果UI组件用得很多，你在浏览器查看生成的html页面源代码中，会有很多动态生成的js函数。 1.自己写的js虽然稍微有点麻烦，但是更加直接，很多初级开发人员都可以维护。另外更重要的是可以重用。不同的页面可以重用js的代码；从这个角度来说开发效率并不低，而且性能更快。 2.由框架产生的事件js。虽然看起来技术很先进。但是维护不方便。另外更不好的地方是重用性（不是ui组件开发重用）和效率非常的差。不同页面甚至同一个页面动态产生的js都不能重用的。比如你在一个页面中使用了十几个日期，最终你会发现在生成的html页面中会由十几个类似的js函数。严重的情况，可能会使生成的html超过1M大小。性能会非常的低（动态生成js和下载页面都需要大量事件）。很可能你后来逻辑只需要很少的处理事件，而在页面暂时的时候却花费了大量时间，这非常不值得。 |
| 返回顶楼 | |
|
发表时间：2007-05-09
其实无论如何
一定会有其它框架的 .net没有其它框架是因为它的很多东西不开放，想在它的基础上做框架，很难! 但象OJB.Net,Hibernate.Net,Ibatis.net是对数据库操作的封装，在Net平台都出现了! 也就是.Net专有的东西是没有办法形成框架的，而通用的东西一定会有。 一句话:有三个人的地方,就会有两派意见! |
| 返回顶楼 | |
|
发表时间：2007-08-06
看了大家的辩论，受益匪浅！ 希望这样的辩论能多有几次！
|
| 返回顶楼 | |
|
发表时间：2007-09-21
目前我只用过ROR和JSF 基本上我认为JSF开发出来的东西 只能在一个应用中使用，而且如果用第三方的结合了AJAX框架的东西， 基本上封装得认不了了 ， 所以我个人还是喜欢ROR 因为就算过一段时间去看以前写的页面， 一样很容易改动或者重新扩展， 现在GRILS出来了，希望能实现一样的东西。 不想用那不像样的JSF，就算是用大厂支持，对于我们程序员， 不是什么好事。 况且GRIALS也有大厂支持了。 个人意见，喜欢GRAILS的可以一起讨论， 期待GRAILS与EJB和JPA结合，让编程来得更加快乐些吧~~
|
| 返回顶楼 | |
