2007-09-21

表现层该由谁来做！？

发言要等3天阿,终于等过了阿.....

表现层该由谁来做！？程序员，还是美工，还是会美工的程序员，还是会程序的美工？

现在在java中流行的表现层处理方法，基本分为以下几种：
1.用jsp的tag
2.velocity之类的脚本
3.javascript填充数据

从技术上讲，可能大部分程序员都会习惯第一种方法，众多的框架也在用第一种方法扩展自己的表现层能力。比如struts等等。可是大家用了这个以后有没有一种感觉，那就是页面要改起来太难了，特别是给一般的美工进行修饰的话，美工基本拿那些tag没有办法。所以，最后的整合工作还是落在了程序员的头上。可是要找到一个审美观优秀的程序员，基本跟找到一个会写程序的美工一样难。呵呵，产品的结果就不必多说了，一般只能达到“看得过去”这个档次。

用velocity之类的，也同样有第一个方面的问题，虽然语法较为简单，但是毕竟是一门新的语法。要美工掌握的话，还是需要培训。

用javascript可能就会比较灵活，基本上页面如何变化都能适应，不过问题也是明显的，只要客户端不允许运行javascipt，或者客户端使用怪异的浏览器，表现层就彻底歇菜。

我们现在项目中采用的方法，是仅在jsp中使用el和jstl的部分语法，这样美工很轻松就能掌握，美工也能用所见即所得的工具（frontpage或dreamweaver）直接进行页面编辑。而逻辑部分我们使用了类似struts的action来进行处理（实际上，我们有一个自己的框架，包括orm,rro，json等功能,而且基本不用配置）。这样，美工和程序员只要约定表单内容，工作基本上就可以完全分开，各做各的。最后只需要用美工的页面覆盖程序员自己的测试页面，作一遍整合测试就可以了。

不知道各位在这方面是如何协调专职美工和程序员的工作呢？
评论
johnnyhg 2007-12-10
timerri 写道
发言要等3天阿,终于等过了阿.....

表现层该由谁来做！？程序员，还是美工，还是会美工的程序员，还是会程序的美工？

现在在java中流行的表现层处理方法，基本分为以下几种：
1.用jsp的tag
2.velocity之类的脚本
3.javascript填充数据

从技术上讲，可能大部分程序员都会习惯第一种方法，众多的框架也在用第一种方法扩展自己的表现层能力。比如struts等等。可是大家用了这个以后有没有一种感觉，那就是页面要改起来太难了，特别是给一般的美工进行修饰的话，美工基本拿那些tag没有办法。所以，最后的整合工作还是落在了程序员的头上。可是要找到一个审美观优秀的程序员，基本跟找到一个会写程序的美工一样难。呵呵，产品的结果就不必多说了，一般只能达到“看得过去”这个档次。

用velocity之类的，也同样有第一个方面的问题，虽然语法较为简单，但是毕竟是一门新的语法。要美工掌握的话，还是需要培训。

用javascript可能就会比较灵活，基本上页面如何变化都能适应，不过问题也是明显的，只要客户端不允许运行javascipt，或者客户端使用怪异的浏览器，表现层就彻底歇菜。

我们现在项目中采用的方法，是仅在jsp中使用el和jstl的部分语法，这样美工很轻松就能掌握，美工也能用所见即所得的工具（frontpage或dreamweaver）直接进行页面编辑。而逻辑部分我们使用了类似struts的action来进行处理（实际上，我们有一个自己的框架，包括orm,rro，json等功能,而且基本不用配置）。这样，美工和程序员只要约定表单内容，工作基本上就可以完全分开，各做各的。最后只需要用美工的页面覆盖程序员自己的测试页面，作一遍整合测试就可以了。

不知道各位在这方面是如何协调专职美工和程序员的工作呢？

最重要的是要找一个：会写CSS+DIV的美工！这样程序员的工作省了一大半了。
kingjzd 2007-12-10
俺们美工就做个CSS+图片
sqhe18 2007-11-17
我们有专门做ui的程序员。大概的流程是：美工作图片=》ui程序员制作html js等=》后台程序员填上后台的逻辑。
zhangpeng8394 2007-11-17
应该各负其则啊，要是什么都由程序员作了，美工不就失业了
所以美工应该试着把自己的饭碗抢回来[b][size=18][/size]
pacer123 2007-11-16
这个可是不同的公司有不同的要求啊，我们之前做的项目，是前台展现层跟后台的业务逻辑都自己写，除非遇到一些页面上显示不美观的问题才去请教美工让美工调！汗那ing。。。。。
tigershuang 2007-11-15
timerri的想法不错，我们也有这样的问题。

不过真正要实现美工和程序完全分离似乎也没有必要。毕竟用户关注的结果，只要结果好，过程有多麻烦又有谁会在意呢？
抛出异常的爱 2007-11-15
xellos 写道
hyhongyong 写道
美工不需要知道什么表现层，只做好静态页面就行。
什么都会的人，价格也高啊。



什么都会的人,在职位不太分明的公司,的确价格比较高.那些公司喜欢全能型人才.

不过如果去IBM面试,说自己会切页面,精通css,会美术设计,会photoshop处理图片,会做flash,会flex,还会java写程序.人家回问你:你到底会什么.
ME啊
pengjun_lovecoding@hotmail.com 写道
tapestry 写道
美工是搞设计的，从web2.0以来，其实出现了一个新的中间的职业，不知道怎么称呼，也就是会切片，懂css和基本的javascript的，而且切完后用div重新规整代码的，这样的人员真是美工和程序员之间不可或缺的粘合剂呀，有这么个人员，谁都happy，没了他，谁都难受。不过现在看来这个角色还是程序员在当呀。


现在这种让人happy的伙计太少，boss说要品质。于是程序员自己掏腰包买了javascript，Css，div狂肯。之后，boss说伙计你能不能做的精致点... 我现在的写照...

tapestry就是作这个用的。
pengjun_lovecoding@hotmail.com 2007-11-14
tapestry 写道
美工是搞设计的，从web2.0以来，其实出现了一个新的中间的职业，不知道怎么称呼，也就是会切片，懂css和基本的javascript的，而且切完后用div重新规整代码的，这样的人员真是美工和程序员之间不可或缺的粘合剂呀，有这么个人员，谁都happy，没了他，谁都难受。不过现在看来这个角色还是程序员在当呀。


现在这种让人happy的伙计太少，boss说要品质。于是程序员自己掏腰包买了javascript，Css，div狂肯。之后，boss说伙计你能不能做的精致点... 我现在的写照...
triu 2007-11-14
realorg 写道
现在很多 平台(一些软件公司的)都将很多功能封装了，很多情况下，后台和业务都可以可视化的定制，而前台允许程序员自由发挥。

这种情况下，都是程序员先将一些元素建立出来，交给美工去美化。


不再在页面中嵌入代码是一种理想的开发模式，相信会很有前途。
realorg 2007-11-14
现在很多 平台(一些软件公司的)都将很多功能封装了，很多情况下，后台和业务都可以可视化的定制，而前台允许程序员自由发挥。

这种情况下，都是程序员先将一些元素建立出来，交给美工去美化。
xellos 2007-11-14
hyhongyong 写道
美工不需要知道什么表现层，只做好静态页面就行。
什么都会的人，价格也高啊。



什么都会的人,在职位不太分明的公司,的确价格比较高.那些公司喜欢全能型人才.

不过如果去IBM面试,说自己会切页面,精通css,会美术设计,会photoshop处理图片,会做flash,会flex,还会java写程序.人家回问你:你到底会什么.
bluemeteor 2007-11-14
如果楼主希望了解在正规，传统的企业开发中表现层的相关概念，请到AJAX板块里面参照JellyMe朋友的一个非常棒的帖子

这里百分之八十的回复让你的帖子更像一个对中国现有软件企业开发模式的调查
xellos 2007-11-14
marcian 写道
我觉得美工(设计)+前端开发(XHTML+CSS+JS)+后台是合理的组合，也是将来的趋势。
PS：我一点都不喜欢使用tag，特别讨厌，有和我一样感觉的人吗？


个人感觉跟你一样,非常不喜欢tag.
但是我是jstl的支持者.
非常厌恶struts等框架又造出的那一套tag.
不过有些tag,比如struts里的表单相关的tag,可以确实带来一些方便的除外.
不过举个例子,struts1.x 里的logic下的所有tag,基本是在重复造轮子.无聊之极.除了增加学习成本,没看到什么好处.循环输出什么的,用jstl就挺好.
我们在某些情况下需要一点统一,不要重复造轮子,不要无故增加学习成本.
xellos 2007-11-14
timerri 写道
或许把UI的制作者叫做美工太偏激了点...虽然我们内部把做界面开发的都称为美工。


我不认为"美工"是个低级的称呼,虽然我们并不这么称呼.

我们公司是互联网公司.有严格的分工.
有 产品 设计 制作 程序 四种职位.
产品就不用多说了,就是策划产品的专员.由他们来提供逻辑,用户流程.
设计是针对页面进行设计的,就是页面长什么样子.他们的结果是出每个页面的jpg图片.
制作 是拿设计的jpg图片,把它们"切页面".切成标准的html 页面的网页制作人员.
程序 就是最后一道步骤了,加入动态的程序.


怎么样,看起来挺完善的吧?

但是世界工作起来却并不那么顺心.尤其编辑跟程序打交道的时候.因为编辑们好象分不清这四种职位.他们知道有问题找程序.
triu 2007-11-14
marcian 写道
我觉得美工(设计)+前端开发(XHTML+CSS+JS)+后台是合理的组合，也是将来的趋势。
PS：我一点都不喜欢使用tag，特别讨厌，有和我一样感觉的人吗？


是的，非常讨厌tag，赞成你的方法，XHTML可以使用XML+XSLT来做，Cocoon就是这么做的，不过Cocoon的Site Map不好管理，所以自己根据Cocoon的原理搞了一个框架，感觉还不错，最近，了解到OSGi，所以想在框架里增加对热部署的实现。
marcian 2007-11-10
我觉得美工(设计)+前端开发(XHTML+CSS+JS)+后台是合理的组合，也是将来的趋势。
PS：我一点都不喜欢使用tag，特别讨厌，有和我一样感觉的人吗？
shenfeng_boy 2007-10-31
呵呵，我们就不会像上面同仁那么累了，我们的系统是自动生成的JSP页面，有一个专门的JSP模板程序负责生成页面，所需的字段类型从数据库取得，这样生成的页面风格也很统一，不过维护起来很是麻烦，需要熟悉数据库页面配置字段，所以公司没有一个美工，都是程序员来处理页面和功能
zhyun29 2007-10-31
tapestry 写道
美工是搞设计的，从web2.0以来，其实出现了一个新的中间的职业，不知道怎么称呼，也就是会切片，懂css和基本的javascript的，而且切完后用div重新规整代码的，这样的人员真是美工和程序员之间不可或缺的粘合剂呀，有这么个人员，谁都happy，没了他，谁都难受。不过现在看来这个角色还是程序员在当呀。

哈哈，这样的人才我们公司就有一个，程序员太幸福了，幸福的都快被惯坏了，哈哈，大家羡慕吧
jimmy_c 2007-10-31
我们应该算是大公司了，但不是做Web的，UI也不是主要的工作。在这种问题的解决中，有三个类型的角色：
1. 用户接口设计师。根据需求和界面设计经验，“画”出一个要实现的界面。他需要考虑：客户需求；本地化需求；界面风格统一等问题。
2. 程序员。根据1提出的要求，实现界面及功能。多数简单的需求就不用麻烦1来设计了。对于需求变化或比较复杂的界面设计时，可能要请1来帮忙设计。
3. 美工。很少使用。根据2或1的要求，做一些诸如色彩调配，css设计等工作。
triu 2007-10-19
所以一直试图将管理、内容、业务逻辑和样式分开，开始很看重Cocoon，后来发现Site Map相当难管理，就没在项目中用它，直到最近才想到不使用Site Map的方法，就是用功能目录（就像servlet的部署描述，带上参数），解决掉Cocoon管理上的问题，事情就变得比较简单了。
发表评论

提醒: 该博客已发表在公共论坛，博客所有留言会成为论坛回贴，留言请注意遵守论坛发贴规则

您还没有登录，请登录后发表评论

timerri
搜索本博客
最近加入圈子
存档
最新评论