|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-05-09
giginet 写道 velocity也相当与一门简单的页面描述语言啊，和jsp的语言有什么区别呢，我感觉的区别就是 jsp是用java写的，语言比较丰富，所以你可以在页面中乱写一气，只要不出错就好。而velocity的页面语言比较少，比较死，所以你不可以乱来。但是jsp控制的好的话也一样可以做到啊，功能多点难道还不好么？
JSP 的功能当然很强大，强大到可以执行 drop table xxx 或者 rm -rf /。JSP 需要这么强大吗？不需要。JSP 应该仅仅执行表示逻辑。如果你熟悉 J2EE 核心模式，或者 MVC/Model2，你就会知道 JSP 在整个 J2EE 架构中的定位一向是被限制在只做 View 开发的（有可能采用 JSP 来做 Controller，但是在任何 MVC 框架内我都没有见到过这种实现方法）。为了避免引起不必要的麻烦，采用 Velocity 或者 FreeMarker 来做开发是更加安全的做法。 giginet 写道 至于美工的问题，我个人觉得，美工的工作就是做图，再放松一点，可以来做html静态页面，将修改后的jsp页面交给美工去美化本来就是一个极不负责任的做法。
我同意这段的说法。我以前所在的团队里面，所有的 HTML 都是由程序员来制作和修改的。美工仅仅制作图片，或者用 PS 做出页面的样子来指导程序员制作页面，以及帮助程序员做好页面的配色。我们分配任务以一个用户能够看到的完整的功能点为单位，程序员前台后台的代码一肩挑。其实虽然我负责整个项目（作为项目经理），我本人也承担了一些功能点的开发任务（其中包括一些程序员不愿意承担的制作修改 HTML 的那种脏活。我不知道在当前这种恶劣的就业环境下为什么还会允许这样的人耍大牌。如果落在我的手下，这些工作你乖乖地去给我做好，否则就给我滚蛋）。所以你们发现我对 HTML/CSS/JS 非常熟悉是一点也不奇怪的。不要以为美工的工作很轻松，一个美工往往要同时为几个项目组服务，加班是常事。美工的工作强度其实不比程序员低多少，所以大家还是需要相互理解。 giginet 写道 可是无论哪一种，你都逃脱不了在页面中嵌入与程序有关的代码，这里只是代码以一种什么形式插入到页面上什么地方的问题。
不是这样的。如果基于类似于 Ajax 的架构来做开发，页面中最多会有一些 JS 代码。而最佳实践是把所有 JS 代码放到单独的 .js 文件中。最多需要在页面某些部分添加一些 id 属性。请看： http://www.digital-web.com/articles/separating_behavior_and_structure_2/ 这样完全分离了 behavior 和 structure 之后，HTML 文件里面就只剩下纯的 HTML 了。还有一个最佳实践是把 presentation 和 structure 完全分离，这需要依靠 CSS 来做到。更进一步，还可以把 presentation 和 behavior 完全分离开。 页面开发不一定是体力活，关键是你要精通 CSS 和 JS，把我上面说到的 presentation、structure 和 behavior 完全分离开，并且能想出一些巧妙的方法来解决问题。页面开发完全有可能成为充满乐趣的工作。将来我贴一些资源大家来学习一下。 WW2 相对于 Struts 肯定是更好的解决方案。开发起来效率也会更高。但是 WW2 并不是我心目中理想的 Web 解决方案（问题不是它基于 JSP/Taglib，而是它基于 HTML Form，因此无法避免我以前说过的基于 HTML Form 的请求/相应模式所固有的一些问题）。它是一个 MVC 的架构，而不是一个 RIA 的架构，它只解决了表示层的一个主要问题。 对于你说的一些问题，SiteMesh 相对来说是一个比较好的解决方案，有空了可以看看。 |
| 返回顶楼 | |
|
发表时间：2005-05-09
dlee 写道 而最佳实践是把所有 JS 代码放到单独的 .js 文件中。最多在页面某些部分添加一些 id 属性。请看： http://www.digital-web.com/articles/separating_behavior_and_structure_2/ 这样完全分离了 behavior 和 structure 之后，HTML 文件里面就只剩下纯的 HTML 了。还有一个最佳实践是把 presentation 和 structure 完全分离，这需要依靠 CSS 来做到。更进一步，还可以把 presentation 和 behavior 完全分离开。 这样的页面结构 太爽了。 可是，国内这样水平的 js / xhtml / css 高手 很难找啊。 而且，公司不是我自己的公司，一般的公司，不会太注重页面。 如果我自己有一天开了公司，我一定不惜高价，雇用这样的 页面设计人员。（所以，我这种人 开不了公司，因为分不出轻重。:D 或者，这样的牛人，有钱也请不到阿） dlee 写道 对于你说的一些问题，SiteMesh 相对来说是一个比较好的解决方案，有空了可以看看。 SiteMesh 被多人、多次推荐过。我没有具体应用过，只看过SiteMesh的Sample, Demo, Document. 实现 定义好 decorate 占位符，然后，sitemesh filter 根据这些占位符 进行 decorate. 这也是一种 静态配置的方式。和 jsp:include, struts tiles taglib 之类的静态布局包含技术，没有什么本质的区别。 |
| 返回顶楼 | |
|
发表时间：2005-05-09
buaawhl 写道 这也是一种 静态配置的方式。和 jsp:include, struts tiles taglib 之类的静态布局包含技术，没有什么本质的区别。
SiteMesh 能做到的似乎 jsp:include 都能做到。但是 SiteMesh 最大的好处是灵活性。 jsp:include 的做法其实和 SSI 没有多大区别。SiteMesh 并不是简单的 SSI，它借鉴了现代 C/S 结构 GUI 应用的一些开发方法，主要就是基于 Decorator 和 Composite 两种设计模式。 jsp:include 是写死在页面里面，而 SiteMesh 可以动态配置。SiteMesh 可以解析内容页面，从其中抽取 HTML 内容。SiteMesh 还可以把一个小的 HTML 内容页面当作一个对象来使用。 SiteMesh 不是完美的，但是 SiteMesh 确实促进了 HTML 页面的组件化开发，我们可以从一种面向对象的角度来思考表示层所有页面的结构，而且 SiteMesh 有效地分离了页面制作人员和程序员的工作。这些是 jsp:include 很难做到的。 |
| 返回顶楼 | |
|
发表时间：2005-05-09
用多了肯定会影响速度.
view面向对象是程序员思维. 美工人员未必能得到好处 客户更不会关心您的view是否面向对象. 真的改起版来 面向对象的view可能更麻烦更死板. 程序员应该做的就是如何根据需求提供数据 如何显示应该彻底放权给美工 和专业的交互设计师. 不能要求美工去处理rowset 集合这些东西 但完全可以让美工掌握xml. 最合理的方式就是程序员输出xml 美工处理xml 交互设计师控制js xmlhttp. 程序员阶段的view组合处理 就是简单的合并xml. |
| 返回顶楼 | |
|
发表时间：2005-05-10
myy 写道 “多看看别人是怎么做的”----也许对于我来说，确实应该要多多加强学习，但buaawhl前辈应该更有发言权，否则也不会去自己做fastm了... :-) 我的经历比较特殊。 我接触到一些非常复杂冗长的JSP，要在同一个页面里面，显示查询条件，查询结果，结果明细，还有各种页面之间关联的link。 一个for, if, else 能跨好几页，而且层次嵌套比较深。很难把 { } 对起来。而且没有一个好的可视化编辑器支持。（很多TagLib都是自定义的，Dreamweaver 也显示不了） 这种页面的唯一调试方法，就是 试错法。把程序跑起来，修改刷新页面。看看有没有错误，有没有Exception。然后还要到 xxxx_jsp.java 里面去找对应生成代码中的错误。 所以，我希望把 页面资源部分 和 页面逻辑 彻底分开。便于调试和显示编辑。 后来，我看了一些开源项目的 页面复杂程度。portal, cms, forum 等内容展示相关的 一些关键展示页面的复杂程度 能够达到 上述的情况。 大部分的操作界面，register, login, add, edit, 等的页面结构 都非常简单。JSP, taglib, velocity, freemarker都很适用。自定义的Tag也没有问题。 如果有时间，大家可以把自己觉得足够复杂的页面结构（层次、分支复杂，不仅是HTML Text 长）展示出来。用各种自己觉得舒服的Template Tech展示出来。 以前有过代码擂台这种方式，但是都是以很小的HTML块 为例子，难以体现页面结构的复杂度。 |
| 返回顶楼 | |
|
发表时间：2005-05-10
引用 to canonical:在我所在的这几个公司中，美工都是一对多的，一两个美工支持N多个项目。那么多的tag，要是你的话会怎么想？？
不想讨论美工的问题。每个人工作量需要平衡。在我们的异地开发项目中，程序员忙死，美工闲死。tag技术关键是对所有人有好处。 引用 SiteMesh 并不是简单的 SSI，它借鉴了现代 C/S 结构 GUI 应用的一些开发方法，主要就是基于 Decorator 和 Composite 两种设计模式。
SiteMesh就是tag的一种应用 引用 SiteMesh 有效地分离了页面制作人员和程序员的工作。
dlee的这句话正是美工及前台工程师学习tag的全部意义，也正是我一直想表达的。tag技术可以远远超越SiteMesh的范围。我说的tag不是c:forEach和c:if等jstl标签。 引用 其中包括一些程序员不愿意承担的制作修改 HTML 的那种脏活。我不知道在当前这种恶劣的就业环境下为什么还会允许这样的人耍大牌。
呵呵，我赞同dlee的这句话 引用 一个项目中，自己写的tag应该不会很多，jstl或structs的tag，基本上能够应付大部分的功能了，再加上一个分页的tag，再需要自己写的已经很少了。除非你非要写成tag
公用的功能都可以是tag, 例如 <app:选择人员/> 引用 而最佳实践是把所有 JS 代码放到单独的 .js 文件中。最多在页面某些部分添加一些 id 属性
这就相当于是对tag的enhance。关键是能够有办法实现抽象，实现概念的分离，我们需要的是一种可扩展的tag的概念，至于前台实现还是后台实现只是一个实现层次的问题。 引用 但是 WW2 并不是我心目中理想的 Web 解决方案（问题不是它基于 JSP/Taglib，而是它基于 HTML Form，因此无法避免我以前说过的基于 HTML Form 的请求/相应模式所固有的一些问题）。
对象化之后就可以解决 引用 比起写那个Portal Demo的时候，现在 fastm 又进步了许多。不仅支持IValueSet，还支持POJO。
bean / map dom + fastm template dom = html text 其实fastm可以采用tag语法，它也是一种低层抽象的方式，也可以在tag的框架内完成。 |
| 返回顶楼 | |
|
发表时间：2005-05-10
一个使用tag的portal布局页面
<html>
<head>
<c:lib src="portal_lib.xml" namespace="portal" />
<portal:config/>
</head>
<body>
<portal:page>
<portal:column >
<portal:module id="1001" title="模块 A">
<i frame src="test_mod_a.html" width="100%" frameborder="0" height="100%"/>
</portal:module>
<portal:module id="2002" title="模块 B">
<i frame src="test_mod_b.html" width="100%" height="100%" frameborder="0"/>
</portal:module>
</portal:column>
<portal:dragbar/>
<portal:column/>
<portal:dragbar/>
</portal:page>
</body>
</html>
|
| 返回顶楼 | |
|
发表时间：2005-05-10
canonical 写道 引用 比起写那个Portal Demo的时候，现在 fastm 又进步了许多。不仅支持IValueSet，还支持POJO。
bean / map dom + fastm template dom = html text 其实fastm可以采用tag语法，它也是一种低层抽象的方式，也可以在tag的框架内完成。 一个做CMS的朋友，使用了fastm。就向我提出了这样的要求。 1. fastm 采用 comment 作为 Mark，看起来太不专业了。 （我的回答是，PHP Lib 也是这样的，:D） 2. 有些Online Editor JavaScript Object 会自动trim html, 去掉 comment 。 （这个我无能为力了。这种情况下，其实最好的选择只有Jivan了） 3. Wicket, Tapestry 那种 Tag 多好，看起来多专业。 （ 采用Tag, 会给template解析带来难度。这意味着Template 应该是XML 格式的。 而这方面，fastm 和 velocity, freemarker一样，根本不管template的格式，只要是text 就行。fastm, velocity, freemarker只关心 认识的Mark, 其余的东西一概不理。这给template解析带来了很大方便，所以，fastm 的Parser 的实现难度很小，在我的能力范围内。 采用Tag, 给template解析带来的难度，超出了我的能力范围。如果一个东西的实现如果太复杂，我就会放弃。我比较喜欢 简单容易的东西。 另外，如果 Tag 的跨度太大，嵌套又多，那么一样难以定位。和script 的 if, else 没有什么区别。比如， <logic: if ..........> <logic: if ..........> </logic:if> </logic:if> <app .... > <app .... > </app> </app> fastm的BEGIN, END Name 能够更容易定位一些。表达层次关系更清楚。 ） |
| 返回顶楼 | |
|
发表时间：2005-05-10
引用 fastm的BEGIN, END Name 能够更容易定位一些。表达层次关系更清楚。
这个我看差不多，只是如果你自己从头开始写parser，这样比较容易一些。不过xmlparser是java的标准部分，适当写一些封装，使用起来就非常方便了。 |
| 返回顶楼 | |
|
发表时间：2005-05-10
canonical 写道 一个使用tag的portal布局页面
<html>
<head>
<c:lib src="portal_lib.xml" namespace="portal" />
<portal:config/>
</head>
<body>
<portal:page>
<portal:column >
<portal:module id="1001" title="模块 A">
<i frame src="test_mod_a.html" width="100%" frameborder="0" height="100%"/>
</portal:module>
<portal:module id="2002" title="模块 B">
<i frame src="test_mod_b.html" width="100%" height="100%" frameborder="0"/>
</portal:module>
</portal:column>
<portal:dragbar/>
<portal:column/>
<portal:dragbar/>
</portal:page>
</body>
</html>这个portal layout是用 iframe 实现的，而不是把 各个Portlet 的 内容集中在同一个HTML 中输出。 iframe 的实现难度不高，我喜欢这种做法，虽然不是JSR168标准的做法。另外，如果一定需要在同一个HTML 中输出，XMLHTTP AJAX 可以达到iframe的效果。服务端Portal Server的实现难度降低，不用对Portlet 输出进行缓存和管理，完全由 XMLHttp 控制。每个Portlet 输出都是独立的服务点，XMLHttp 可以分别访问它们。 另外，这个Portal Layout 是写死的。用户无法动态添加、删除、移动这些Portlet Module。 一个Column 里面写死了两个 Portlet Module. 而这些module信息是应该放到 XML 文件或者 数据库中的。 |
| 返回顶楼 | |
