设计、前端和后端


最近在群里看到这样一句话“前后端都搞之后,你就会更好地写页面,有些不懂后端的人写出的页面,根本就不好循环调用的",接着马上有人接上了下一句“前端和设计都搞之后,你就会更好地设计页面,有些不懂前端的人设计出的页面,根本就不好切图的”。

两句玩笑话,却也是现在网站开发中的实情。

最近做项目我也遇到了这一问题,自己写的独立的html页面每一个看起来都没问题,而后端调用的时候总是会出现样式的问题,尤其是提交表单的情况,表单本来我是分成了不同的html文件,结果到了后端手中,需要把这几个表单放在同一个文件里面,由于表单外围包围的class类名不同,所以出现样式丢失、覆盖的情况。然后导致现在做页面也是类名越来越奇怪,越来越长。这显然是一种不好的开发模式,也是由于开始做项目前没有整体规划好,也是自己经验不足。

这就是前端在制作页面的时候需要考虑的重用的问题,一个页面的结构的划分,每一个模块的样式的分析,要在哪个部分加上class来控制样式;样式的控制具体要到哪一级的程度,这样写会不会出现以后修改的麻烦,是否能够在别的地方也用这种样式,是否能够大体也用这种样式,但就是部分不同;你要去改,应该怎么改,会不会出现原来设置的选择器过于详细导致后面的修改都无效的情况。

要想提高页面的重用性,在写样式的时候通过父级元素一层层来选取的方法我感觉是不可取的,这样会导致嵌套的DIV越来越多,样式选取越来愈细而不易更改,同样会导致CSS文件越来越大。好一点的办法应该是分析项目结构,将模块归类,也就是抽象的过程。

更可以像张鑫旭的quicklayout那样,写出一套能适应各种不同设计方案的CSS,只需要在html文件的每个具体元素上面写上众多详细的类名就行了,好处是css文件小很多,但html可能会增加一点。凡事必有利弊。当然,现在项目中对于那一点代码文件的增减不是那么看中。毕竟不是什么谷歌,百度这样用户量极大的网站页面。

前端的事还有很多,作为一个前端,也是不能只学前端而已。路漫漫其修远兮,少年传我影分身术可好?

——下面是一些零碎的东西————

不要对网站通用的东西进行分离:也就是说不要用写众多类名的方式来定义这个东西的样式,原因显而易见,当你要改样式的时候,由于网站众多部分应用了它,你就需要在众多html文件里对他进行修改,电商网站成百上千个页面的,我只能送你呵呵一笑了。

用一层一层的选择器来定义通用的大概的模式,再加上零碎的通用class来实现不同的效果。“大概”的程度根据项目来决定。

如果能在css文件里面的class的大括号{}内再引用其他class就好了;

如果能在css文件里面的class的大括号{}内能定义优先级就好了(其他冲突样式一律无效,只认本样式:覆盖其他样式,涉及到css选择器的优先级),是该好好研究下。

时间: 2024-12-19 02:32:27

设计、前端和后端的相关文章

IC设计前端到后端的流程和eda工具。

IC前端设计(逻辑设计)和后端设计(物理设计)的区分:以设计是否与工艺有关来区分二者:从设计程度上来讲,前端设计的结果就是得到了芯片的门级网表电路. 前端设计的流程及使用的EDA工具如下: 1.架构的设计与验证:按照要求,对整体的设计划分模块. 架构模型的仿真可以使用Synopsys公司的CoCentric软件,它是基于System C的仿真工具. 2.HDL设计输入:设计输入方法有:HDL语言(Verilog或VHDL)输入.电路图输入.状态转移图输入. 使用的工具有:Active-HDL,而

前端和后端如何合作

我们的流程是这样的,后台提供数据接口,或接口文档. 然后我们前台进行razor模板的数据逻辑嵌套或html,css,js整个流程的开发. 缺点是:工作量是满大的,优点是,所有前端view层的东西都是可控的. 坑是比较多的, 比如数据出现问题时,没有一个经验丰富的前端或后端进行联调, 有问题短时间内是解决不了的. 一般跟后台合作分为这几种模式:1. 只产出html页面,然后交给后端来处理数据.这种的好处是工作量比较少,公司没有专门的前端岗位时可以实行这种办法.但这种的缺点也是显而易见的,后端人员工

前端和后端

舞台是展示自己最华丽的一面,那么,后台则是很多工作人员所运转. 一个大舞台,需要的是前端和后端,那么前端是什么,后端是什么? 我们抛开技术不说,举个例子吧! 比如一个大型的演唱会,如果没有一个好的歌手,没有好听的歌,不过光靠歌手还不行,还需要舞台,这个舞台需要谁来支撑呢?没错,就是后面的工作人员,没有他们,就没有这样顺利的演唱会. 如果前端是歌手,那么后端则是工作人员,这样就很好理解了,我们前端是干什么的.但是光靠展示和设计出漂亮的网页还不行,还需要和后端好好配合才能做好,所以这个博文会列举出后

前端和后端工具

工具的分享分为前端和后端工具,前面的1-7条为后台测试常用工具,最后一部分中的众多工具是前台测试工具,感谢搜索应用测试组的同学提供协助! 邮件中所列出的工具,有哪些你不知道如何使用,或者认为有必要做进一步讲解,请告知我们,我们随时倾听你的声音,并据此筹划下一步的分享,谢谢! 1. screen命令 应用场景: 当你运行一个任务,比如make一个大的项目.建立索引的时候,任务的时间很长,在这段时间如果需要断开网络连接(比如想关机.或者网络问题),你的任务将会消失.screen就可以解决这样的问题.

我们前端跟后端是怎么合作的

摘要: 文章背景,来自于群内周五晚上的一次头脑风暴式的思维碰撞交流活动. 我们的流程是这样的,后台提供数据接口,或接口文档. 然后我们前台进行razor模板的数据逻辑嵌套或html,css,js整个流程的开发. 缺点是:工作量是满大的,优点是,所有前端view层的东西都是可控的. 坑是比较多的, 比如数据出现问题时,没有一个经验丰富的前端或后端进行联调, 有问题短时间内是解决不了的. 一般跟后台合作分为这几种模式:1. 只产出html页面,然后交给后端来处理数据.这种的好处是工作量比较少,公司没

对一个前端AngularJS,后端OData,ASP.NET Web API案例的理解

依然chsakell,他写了一篇前端AngularJS,后端OData,ASP.NET Web API的Demo,关于OData在ASP.NET Web API中的正删改查没有什么特别之处,但在前端调用API时,把各种调用使用$resouce封装在一个服务中的写法颇有借鉴意义. 文章:http://chsakell.com/2015/04/04/asp-net-web-api-feat-odata/源码:https://github.com/chsakell/odatawebapi 首先是领域模

前端加后端验证倒计时答题功能实现

思路 前端页面控制答题的开始,请求后台,后台记录开始的时间(发出请求的当前时间),再加上倒计时时间,得出结束时间. 后端返回给前端剩余的时间,前端通过Jquery实现倒计时的动态效果. 当倒计时结束,禁止答题,当用户刷新页面时,比较请求时间与结束时间,如果前者小于后者,答题继续,否则反之. 其中,答题时间.开始时间.结束时间,均保存在内存中. 实现(SpringMVC+Jquery) 后端: 1 /** 2 * Copyright 2016 Zhengbin's Studio. 3 * All

文件上传之前端和后端

明天又是星期一.发现周末的时间过得真快啊.光阴似子弹,嗖的一下,两天就没了. 文件上传是web开发中很常见的场景,比如填写个人信息的时候传一两张自己美美哒照片,比如上传一张个性的头像.有时候需要上传一个压缩包,文档啥的.作为程序员嘛,自然免不了要想办法让这些美照啊,文件啊顺利的到达服务器. 今天我来写一段最简单的文件上传.至于简单到什么程度,那我先介绍一下稍微复杂的文件上传吧. 1.web2.0时代,用户体验是web开发必须考虑的问题,文件上传自然不能跳转,所以,类Ajax的方式上传文件是现代网

前端和后端的双重验证

ASP.NET MVC和WebForm 轻松实现前端和后端的双重验证 jquery.validate+ValidationSugar 上次不足的改进 可能上一个贴子给大家带来很多误解,所以我这次把DEMO完善了两个版本 [ASP.NET WEBFROM]和[ ASP.NET MVC] 修改了一些BUG,并且修改了一些细了 在上个贴子里有人说,看了response.write就全身不舒服,所以也就写了基于异步提交的例子 功能介绍 ValidationSugar.cs 负责后台验证和前端 form

Web前端和后端的技术发展方向

今年web前端被炒得异常火热,但与此同时后端也是备受关注,这让很多web前端和后端的技术人员思考两者的发展方向,下面是小编收集的前端大牛的一些看法. 首先,兴趣是最重要的老师.个人认为除了少数意志力坚定的人,大多数人只有在自己有兴趣的领域才能发展事业. 但是是否"觉得兼容性很枯燥",就一定无法"感兴趣"下去, 这个其实不好一概而论.如果对兼容性问题感到麻烦棘手,这个恐怕很难做好前端.但是如果对探究某个兼容性问题有兴趣,但当探索完毕后,又厌烦每次都要为这个问题写额外的