进行 Web 界面原型设计的一种方法(续)
写于 2008年12月11日 23:18 评论(5)
昨天写到为何XHTML原型会失败?,意犹未尽,再续一篇旧文。
在进行 Web 界面原型设计的一种方法(以下简称MVC/SSI原型法)这篇文章里,漏了一部分,也就是昨天提到的维护或者 CSS/JS 文件共用的问题。其实可以通过下面要讲到的方法,解决一部分。
无论是 XHTML 原型还是程序模板,前端(网页/网站部分)主要包括两大部分:HTML文件和资源文件,其中资源文件又可以分为CSS、JS、背景图(CSS中引用)和内容图(HTML文件中引用)。为了实现可维护、重用,在整个开发过程中,最好的办法是保持一致、只用一个。
以 CakePHP 框架为例(其他框架大同小异),程序渲染用的模板在 /app/views 下,并且分为 layouts、elements 等多个目录。这个分法是很好的,结合MVC/SSI原型法,很利于后期开发。Views 是不能直接查看的,也没有数据内容(样例内容),这一点违背了原型的初衷。应用的根目录是在 /app/webroot 下,为了让原型能够直接给其他协作者查看,可以将原型目录添加在根目录下,比如 /app/webroot/prototype,这样通过 Web 即可以查看。为了让发布版本和原型能够共用 CSS 和 JS 文件(假设目录为 /app/webroot/ui/css 和 /app/webroot/ui/js),需要注意 CSS 和 JS 中的 URL 全部使用绝对路径(不加域名)。
无论是一个人的设计团队,还是多人,都可以将 prototype 目录也加到版本控制中。同时为了使绝对路径能够生效,可以在本地配置 apache(以 PHP 为例,呵呵),比如 local.example.com 访问 /app/webroot/prototype 为原型,www.example.com 访问 /app/webroot 为上线版本。虽然 prototype 不能自动当成 views 用(这有些痴人说梦了),但已经能解决一部分问题了,在某种程度上已经很好维护了。MVC/SSI原型法的优点就是 prototype 目录结构和 views 目录结构是基本一致的。
昨天千鸟给我介绍了他的方法,把界面拆成大大小小的元素(XHTML)去维护(比如搜索、高级搜索、翻页等),这有些接近于 CakePHP 中的 elements 目录,即公用元素,也可以考虑在 elements 目录下放一个 index.html 用于在线查看各个元素的代码和效果。
对了,还会遇到这样一个问题。再原型和开发沟通的过程中,如何减少重复的沟通?比如说除了界面上增加了一些元素,很容易发现,前端代码上的一些细节调整,比如 class 换了一个名字之类的,用以上方法仍然需要前端人员自行或者告知开发人员去修改。这一点,只有 prototype 能直接当 views 用的时候才能解决了。
根据我的经验,这个方法可以很好的运用在简单的项目中,比如 Blog、小型CMS等。对于门户级的、有众多频道的大型网站也可以尝试,具体也要看服务器上的部署,如果分多个应用,那么在各个应用中分别加 prototype,如果是单一应用多个频道,可以在 prototype、ui 目录下再进行细分。
以上内容仅为想法,未实践,相信还会遇到很多未知问题。接下来我也会进行一定的实践,欢迎探讨。
J.
原文地址:http://www.junchenwu.com/2008/12/a_method_of_using_html_to_design_web_prototype_2.html
评论(5)
共用资源文件,会不会有版本不同的问题、
Junchen也是PHP及Cake的爱好者?
一个更好的办法是,把view交给它本来的主人-前端开发-来编写和管理。如果不会PHP/Java的话,完全可以使用简单的模板语言,比如PHP里面的Smarty,Java的Velocity。
我顺着你昨天的文章又写了两篇,随后会发出来,这里先做个广告,呵呵。
@Felix 我是在以前的项目中用过Cake,觉得这个框架的Views处理的不错。至于说 PHP,我只会改改 WP 什么的,呵呵。给前端编写和管理的话,要看这个角色是不是细分的足够,是在哪个部门。我所经历过的都是前端是在设计部门或者UED部门的,这时候 Views 部分还是给程序的好。
哥,你给思路太好了,有时间一定去好好的实践下。
web原型 跟 views模板之间 本身就是不同的东西
要么 是把web原型的直接当成 views模板来做
要么 是先弄出来web原型 再交给程序来做成 views模板
把两个弄到一起?? 感觉维护起来更麻烦了... (要改就要改两个... -_-!!)