使用UML设计HTMl&CSS架构

yuanyun 楼主

这张图是UML构建的 前端图. 看查看原图


mmmm.不太清楚国内的重构工作人员是否 有用uml来规划整理自己的html&css的全站架构.
或者,大家如何清晰明了化整个项目重构的编写呢?


想和大家交流:
大家在开动项目之前,如何让自己思维化的想法实现为可视的媒介呢?
希望能够看到很多闪亮的想法....^^

btw:分享 面向对象CSS ppt

by:

[ 本帖最后由 yuanyun 于 2009-11-10 18:13 编辑 ]

YrJian

对前端使用UML对我来说是一个崭新的话题，因为我连想都没这样想过，前端也能像后端架构一样用UML描述？在这之前，我认为是不可想象的，因为UML的一大特点就是OO。不过在初略看了楼主分享的面向对象的CSS设计PPT后，我开始相信前端也能采用OO的思想来设计和实现，CSS本身就是一个继承性很强的语言，那么HTML中元素的CLASS可以有多个就可以看做有点类似于多重继承，呵呵。关于OO的CSS我理解的不是很多，也是之前看别人BLOG种有这种将CSS区分结构和表现，然后分别将各种结构和表现的CLASS赋予元素，就像是OO开发中的模块，组件一样，通过多个组件的配合来实现更大范围的重用。楼主的这个话题让我对CSS的认识有了一个新的进展，虽然我对UML也不是很熟，但是关于这种思想在前段开发中的应用我是非常的有兴趣，希望能和大家更多的交流。

zhutianyi

这种图缺乏实用性。
1. 从思考到动手，做完这张图要多少时间？1天还是2天？
2. 做完之后，它在今后的开发过程中，能发挥几次作用？
3. 当需求变更的时候，还有人有精力去再重新搞这样一张图出来吗？

YrJian

UML图是用来在系统构架的时候随着需求的讨论逐步生成的，主要用于团队开发中用来加强沟通，虽然在一般网站上应用的确是有点繁琐了，但是在大型站点的构架上还是很有用的。这个图的作用是在设计中进行沟通交流的辅助，在开发过程中就可以直接按照图的内容进行编码。它的主要作用不是在图完成后，而是在讨论完善需求和架构的过程中。我是这样认为的。对于大型复杂的站点来说，用一点时间来做并不会影响进度，反而会令需求和架构更完善。至于需求的变更，只需要对图进行适当的修改即可。除非是需求完全推倒重来，不过这样的话，用不用UML又有什么区别呢？

zhutianyi

1. 图上的那是系统构架吗？
2. 在开发过程中根据图上的内容直接进行编码，编不出怎么办？再返回去修改那张图？

YrJian

呵呵，我不是特指这张图来评价，而是说UML适合做系统构架。

至于编不出来怎么办这个问题可能性应该很小吧，毕竟做构架的人对于自己团队的技术水平应该是清楚的，不会做出那种自己团队无法实现的方案来吧？

yuanyun 楼主

或许,你也拥有其他的方式来可视化自己架构前端的规划?

希望能够分享.

yuanyun 楼主

原帖由 YrJian 于 2009-11-10 13:36 发表
UML图是用来在系统构架的时候随着需求的讨论逐步生成的，主要用于团队开发中用来加强沟通，虽然在一般网站上应用的确是有点繁琐了，但是在大型站点的构架上还是很有用的。这个图的作用是在设计中进行沟通交流的辅助， ...

hi 3# zhutianyi
mmmmm...我们暂且 不讨论这张uml图片吧,
更想知道,如果,当您接到了一个100pages以上的设计稿,  您会如何让自己的前端架构可视化呢?

很期望 您能分享 您的方法

我想,
各位人士一定都有自己非常熟练的方式来形象化自己的前端架构.
发此贴的目的,也正是如此.
为了学习,了解更多的方式.

by:元云

[ 本帖最后由 yuanyun 于 2009-11-10 17:18 编辑 ]

YrJian

呵呵，说实话，对于前端开发架构的可视化来说，我也没有什么好方法。。。。因为我们在讨论的时候都是在白板上画出来的。。。。并没有使用UML这种很精细的描述来实践过，所以在方法分享上可能让你失望了。。。。因为我更主要的任务是在后端，所以对于OO思想的运用略有心得，今天突然发现你的帖子将其与前端的架构联系起来，让我有种豁然开朗的感觉，以前从没这么想过，特别是你分享的PPT给我的感触很大

也就是说，除了在白板上简要画出系统的主要结构外，在架构可视化方面我几乎没有其他的经验，还望能在这里学到更多东西~呵呵

31666595

第一次听到 这个概念，，一直都没有接触过。。我在工作中基本上都是 跟着感觉走，随便在纸上写写，理出一个简单的思路，这样子。。。也没有具体讨论过框架，，所以在后续的工作中会感觉特别混乱，总是乱乱的感觉。。

今天啦到这个UML，感觉 值得学习一下。。这样做至少自己会觉得思路很清晰

yuanyun 楼主

原帖由 YrJian 于 2009-11-10 16:41 发表
呵呵，说实话，对于前端开发架构的可视化来说，我也没有什么好方法。。。。因为我们在讨论的时候都是在白板上画出来的。。。。并没有使用UML这种很精细的描述来实践过，所以在方法分享上可能让你失望了。。。。因为我 ...

mm...这个构思也不是我原创的,都是国外的知识,学习借鉴,很不错.

"除了在白板上简要画出系统的主要结构外" ,这也是一种很好的方法呀,变为可视化了.

只是,我想如果某人要亲自编写前端代码,那么他会明白,系统主要的结构不会是什么大难题,难题应该会出现在,分离,共用,特殊的安排上..,oo-css 会很优美.

每个人页面重构工程师都是建筑工人,
大家手里的砖块都是一样的,不过,搭建后的建筑,有的整洁优美,有的可是杂乱无章呀

anyway ,谢谢你的关注.

YrJian

的确，如果CSS能够以OO的方式设计和实现，那么不仅视觉上好看，维护上也会更方便。

而要实现这些，最主要的就是在你说的分离，共用上。如何把页面抽象成各种组件，并不是一件容易的事，尤其是在页面数量很多，个性化比较强的时候，这种抽象就很费神了。

从你分享的PPT中看，它提出了2个主要的分离，结构和表现，容器和内容。其中结构和表现在我们一般的理解中其实就是将HTML和CSS分离，讲究良好的语义化结构，在此基础上来进行CSS的表现实现。而容器和内容，我觉得就主要可以在CSS中进行分离尝试，将容器和内容的表现分别实现，形成一个个组件，不同类别的容器分别用不同的class实现，然后内容的具体修饰用另外的class实现，在HTML和CSS的结合时就可以组合运用多个CLASS来实现具体的表现效果，如果出了问题，也可以讲问题锁定在更小范围的代码内，方便解决。。。。而组件的作用就是重用，那么相对来说就减少了文件的尺寸，对于高流量的网站来说，服务器的性能也会相对有所提高。虽然幅度不大，但毕竟更好一点了~呵呵

zhutianyi

1. 前端架构可视化的目的是什么？做的话方便了谁？不做的话会有什么影响？
2. 就拿100pages的项目来说，是等设计师把画面全部设计出来后在开发呢，还是设计一部分开发一部分？uml图何时做？

我想先把这些问题弄清了，再来讨论如何做前端架构可视化才有意义。

yoom

引用：当您接到了一个100pages以上的设计稿。

这其实是设计人员的事情了，前端开发者只能提点自己的意见，这也是为什么大公司都要求设计人员至少要了解xhtml+css，才有利于前端的psd输出为xhtml+css。

对于UML来规划，个人觉得有时间，当然可以把工作的更细致，但一般公司哪有这么多时间呢？

这时候，就需要一个“前端架构师”，支付宝招聘就有这么个职位了！

我设想的前端架构师的职责是：负责发现设计稿中的共同点，然后着手编写global.css(最顶级的共有样式表)，其他页面的私有样式可以交给前端开发者来做（注意：前段架构师不负责的，仅仅监督一下）。并且，任何人未经允许都不能动global.css。

前端架构师负责大的方向，比如共有样式表中，类的命名，xhtml的结构最优化。

好想回归！

yuanyun 楼主

[ 本帖最后由 yuanyun 于 2009-11-10 17:49 编辑 ]

yuanyun 楼主

原帖由 YrJian 于 2009-11-10 17:22 发表
的确，如果CSS能够以OO的方式设计和实现，那么不仅视觉上好看，维护上也会更方便。

而要实现这些，最主要的就是在你说的分离，共用上。如何把页面抽象成各种组件，并不是一件容易的事，尤其是在页面数量很多，个性 ...

那,我细读你的文字告诉你我的想法好么?

1)."它提出了2个主要的分离，结构和表现，容器和内容。其中结构和表现在我们一般的理解中其实就是将HTML和CSS分离，" 这里的 "结构和 表现" 我理解为,css中 定义 结构 和表现的 不同类名,而不是 html结构和css表现.

2). 容器和内容 的理解上我们是一致的.

也就是说,我理解为,oo-css 是用css ,分离: 结构, 容器, 表现,和内容 (或者制作者依据自己的要求分离的更详细).

然后就能实现了你说的"在HTML和CSS的结合时就可以组合运用多个CLASS来实现具体的表现效果，如果出了问题，也可以讲问题锁定在更小范围的代码内，方便解决。。。。而组件的作用就是重用，那么相对来说就减少了文件的尺寸，对于高流量的网站来说，服务器的性能也会相对有所提高。虽然幅度不大，但毕竟更好一点了~呵呵"

by:元云

[ 本帖最后由 yuanyun 于 2009-11-10 17:48 编辑 ]

yuanyun 楼主

原帖由 31666595 于 2009-11-10 17:08 发表
第一次听到 这个概念，，一直都没有接触过。。我在工作中基本上都是 跟着感觉走，随便在纸上写写，理出一个简单的思路，这样子。。。也没有具体讨论过框架，，所以在后续的工作中会感觉特别混乱，总是乱乱的感觉。。 ...

yuanyun 楼主

原帖由 zhutianyi 于 2009-11-10 17:36 发表
1. 前端架构可视化的目的是什么？做的话方便了谁？不做的话会有什么影响？
2. 就拿100pages的项目来说，是等设计师把画面全部设计出来后在开发呢，还是设计一部分开发一部分？uml图何时做？

我想先把这些问题弄清 ...

hi  zhutianyi  
我就以自己的思想来回答你的问题好么?

问题1. 前端架构可视化的目的是什么？
[我的目的是:为了让我的真个项目不会做到混乱的局面.分离每个类别的定义,最好最高的可复用性和可组合型.]

做的话方便了谁？不做的话会有什么影响？
[呵呵,这个问题,也许我会说,方便了我自己,也方便了阅读者,维护者,不做的话,我想我会让自己的项目走到后面会混乱.]


问题2. 就拿100pages的项目来说，是等设计师把画面全部设计出来后在开发呢，还是设计一部分开发一部分？uml图何时做？
[我们的流程是,接到设计师设计好的所有设计稿(一个压缩包),里面拥有的设计稿至少占整个项目页面95%以上,然后开始我们的重构工作...就到了今天我讲的话题了]

这些问题,现在我用自己的方式回答了你, 很渴望得知您的工作方式是?


这是一个开放的世界,我们很愿意知道,了解到更多的方式 .....你是否也愿意呢?

依据自己的目的.选择自己合适的

yuanyun 楼主

原帖由 yoom 于 2009-11-10 17:38 发表
引用：当您接到了一个100pages以上的设计稿。

这其实是设计人员的事情了，前端开发者只能提点自己的意见，这也是为什么大公司都要求设计人员至少要了解xhtml+css，才有利于前端的psd输出为xhtml+css。

对于UML ...

wow...

"我设想的前端架构师的职责是：负责发现设计稿中的共同点，然后着手编写global.css(最顶级的共有样式表)，其他页面的私有样式可以交给前端开发者来做（注意：前段架构师不负责的，仅仅监督一下）。并且，任何人未经允许都不能动global.css。"

这个定义,我浅薄了,从来未知,一直以为,"负责发现设计稿中的共同点，"也该有页面重构编写者自己 搞定.

maybe ,you are right.

yoom

一直认为，分离的最高境界是：

给一个资深的前端开发者一篇的xhtml，他能从文档中获知内容，但不能获知表现。
也就是能获取极多的网页内容，但只能获取极少地表现(或表象或布局)信息。

就像禅意花园一样。

这么一个简单的要求，至少需要重构者，定义良好的class和id名称。
但，如果是这种： .left_sidebar{} ，那位开发者就知道左侧可能有一个侧栏，显然这是一篇并不算很好的xhtml文档。

降低xhtml对css的依赖非常重要，一开始就必须认真对待。

---修改一下
不知道当时禅意花园的作者，是怎么设计xhtml结构的，画图了么？

[ 本帖最后由 yoom 于 2009-11-10 18:43 编辑 ]

yuanyun 楼主

yoom:
"一直认为，分离的最高境界是：

给一个资深的前端开发者一篇的xhtml，他能从文档中获知内容，但不能获知表现。
也就是能获取极多的网页内容，但只能获取极少地表现(或表象或布局)信息。

就像禅意花园一样。

这么一个简单的要求，至少需要重构者，定义良好的class和id名称。
但，如果是这种： .left_sidebar{} ，那位开发者就知道左侧可能有一个侧栏，显然这是一篇并不算很好的xhtml文档。

降低xhtml对css的依赖非常重要，一开始就必须认真对待。

---修改一下
不知道当时禅意花园的作者，是怎么设计xhtml结构的，画图了么？"




"离的最高境界是：给一个资深的前端开发者一篇的xhtml，他能从文档中获知内容，但不能获知表现。
也就是能获取极多的网页内容，但只能获取极少地表现(或表象或布局)信息。...降低xhtml对css的依赖非常重要，一开始就必须认真对待。
"

似乎不需要回复你的内容,因为我的观点一致.


只是,我会更愿意看到你的实施方法or建议工作流程. 当然可以不用画图,


btw:对于禅意花园,个人认为,那不是最高境界,只是基本要求.^^ .


"不知道当时禅意花园的作者，是怎么设计xhtml结构的，画图了么？" -> 也许,可以mail给Dave Shea问问
他很友善的.

yoom

看什么项目吧。比如你说的，如果设计师传给你100个设计页。

如果这100个页面都有相似的地方，比如相同的导航，版权，列表（指表象）。不同的只是布局方式，我就采用公有CSS+私有CSS的方式，这样根据需求，来灵活处理公有样式表和私有样式表的内容。

当发现私有样式表中频繁出现了雷同样式的时候，我就会考虑将该样式迁移到公有样式表中。同理，当公有样式表中某个样式特别冷门的时候，就转移那个样式到对应的私有样式表中。

在公有样式表的头行中，我写上了这句话：

1. @charset "utf-8";
   
2. /*
   
3.         ------------------------------------------------------------
   
4. 
   
5.                 Copyright by:****分公司 | http://******/
   
6. 
   
7.                 Date:2008-11-26
   
8. 
   
9.                 [b]该样式表作用于大部分页面，因此必须慎重的[增、删、修]该样式表。[/b]
   
10. 
    
11.                 该样式表最失败的类之一：ul.normal_tab ，语义极差。按道理应该用hx来替代。
    
12. 
    
13.                 by：yoom
    
14.         ------------------------------------------------------------
    
15. */

复制代码

而私有样式表，则单独处理各个页的不同，命名就   xhtml文档名.css。

我作法是，一个页面至少两行样式，第一行引用公有样式表，第二行引用私有样式表。
当某个页面需要废除，直接删除该xhtml文档和对应的那个私有样式表，其它页面不会受到影响，也就是各个页面和公有样式表关联度极高，而各个私有样式表之间关联度极低。

因此我的办法是：公有+私有。

难就难在公有样式和私有样式的判断，第一次的判断都是不准确的，因为设计师可能传一个更新过的效果图给你，这就会导致结构变化，跟着css也就变化。所以公有样式表和私有样式表，始终在不断的互动。

如果时间充裕，画图倒不失为一种办法。


但也有极端情况，比如两张效果图雷同的地方很少很少。就单页+单CSS结合来吧。

Missx

我和楼上的做法差不多。只是因为行数少，公有和私有一般是放在一个文档里面的。楼上的说法很像程序里面说的高内聚和低耦合。
另外，目前中国很少有人能和YAHOO比。要知道YAHOO在前端上的投入可不是一般企业能比的....
BTW:我还是倾向于先架构然后直接css，然后针对样式表进行重构。

yoom

原帖由 Missx 于 2009-11-10 20:37 发表
我和楼上的做法差不多。只是因为行数少，公有和私有一般是放在一个文档里面的。楼上的说法很像程序里面说的高内聚和低耦合。
另外，目前中国很少有人能和YAHOO比。要知道YAHOO在前端上的投入可不是一般企业能比的.. ...

是的，我刚才还想用耦合一词呢，但又怕不合适。
还是把这句话说了，大家评判：
各个xhtml文档和公有样式表耦合度越高越好（至少意味着维护方便），而各个私有样式表之间的耦合度越低越好。

sunky2021

- -汗··高深啊··完全不太明白··标个记号周末仔细看看·····

kukuyu55

在设计稿 到 实现过程中 确实很迷糊...收获不小

yuanyun 楼主

谢谢Yoom的分享.
yoom said,

"因此我的办法是：公有+私有。
难就难在公有样式和私有样式的判断，第一次的判断都是不准确的，因为设计师可能传一个更新过的效果图给你，这就会导致结构变化，跟着css也就变化。所以公有样式表和私有样式表，始终在不断的互动。"

这是个很好方式.是一个结果,写完之后的结果 是 "公有+私有"+等等的组合.(我这样认为的)

难就难在公有样式和私有样式的判断

其实,本贴的目的就是想了解,整个项目中这个判断的过程,
编写人员们能够掌握什么方法或者通过什么"动作流程" 来判断公有和私有样式,  大家可以分享出自己的判断过程的方式,
例如,直接边构思边写,
例如,在白板上画出主体结构,
例如,直接在30张设计稿中风别标出你思绪中的结构布局内容,挑出公有私有
例如,你用uml操作出自己的思绪形象化,
.....例如很多很多...

by:

uriel

我觉得就html来说做到结构与模块分离接就可以了，重用方面因为是通过叠加样式实现的，考虑到页面设计会有个持续更新的过程，尽可能控制影响范围，只涉及模块结构即可，btn ico可独立出来共用，基本上做到这样就可以了。

html和css毕竟是很轻量级的应用，我觉得保持它的这个优点很重要，把复杂的事情简单化，把简单的事情模块化是我做页面时的主体思想。

YrJian

呵呵，将按钮，列表标签等等东西独立出来共用，实际不就是实现了组件化吗？如果按照OO思想来看的话，完全可以把栏目的各种容器样式，一些内容的通用样式，例如标题，主内容，时间，链接等等，都可以做成一个个的组件形式，即这种内容的多个不同的形式，然后在不同的地方应用不同的形式即可。这样也并不复杂啊，而且在维护和应用上我认为还相对简单一些了

YrJian

呵呵，耦合度这个问题的确是应该重要的，因为CSS的高度继承性，耦合度不把握好的话，可能会影响之后的很多效果，这也是HTML和CSS结构设计的一大难点