基于BS架构管理系统的设计问题与对策初探

2018-12-28王乾坤

数码设计 2018年5期

王乾坤*

（无锡城市职业技术学院语言创意系，江苏无锡，214001）

引言

基于BS架构的优势是显而易见，不仅升级更方便而且对客户端要求低。客户只需要有一款合适的浏览器即可运行系统。作为管理系统而言与普通网站在设计时存在很大的区别，普通网站的信息多是单向的，客户主要是从网站上浏览数据。而管理系统更倾于与客户的交互，客户不仅要从服务器上获取信息，还需要向服务器提交信息。所以在基于BS架构的管理系统设计时，遇到的问题更改设计要求更高。主要问题集中在浏览器兼容性、提交或显示中文时乱码以及如何实现前端代码的复用性。从以上几方面，笔者从实际设计经验出发进行了分析和总结。

1 浏览器兼容性

当前浏览器市场百家争鸣，不同产品以及各种版本层出不穷。每款浏览器为吸引不同客户群体，设计倾向特性不同。比如360浏览器等面向以浏览信息为主的客户，所以提高浏览网页速度，乃至于不惜牺牲部分交互功能(默认关闭JS功能）。作为基于BS架构的管理系统而言，JS的使用是必不可少的。另外，实现同一功能的JS代码对不同浏览器而言，虽大同而有小异。就这么一点点小异，如果设计不当，小则影响网页效果大则导致设计功能无法实现。

（1）打开第一扇门：先让 JS运行起来。笔者的做法是在登录页即进行侦测是否禁用 JS，如禁用则提示用户必须打开 JS。具体代码是：。

（2）对象获取问题:FireFox获取对象的方法是document.getElementById(“idName”)；而 IE 方法是 document.idname 或者 document.getElementById(“idName”)。统一方法:document.getElementById(“idName”)；

（3）const问题：Firefox可以使用const关键字或var关键字来定义常量；IE只能使用var关键字来定义常量。统一方法使用var。

（4）event.x与 event.y问题：IE的 event对象有 x,y属性,但是没有pageX,pageY属性；Firefox下,event对象有pageX,pageY属性,但是没有x,y属性。解决方法：使用mX(mX=event.x?event.x：event.pageX；)来代替IE下的event.x或者Firefox下的event.pageX。

（5）window.location.href问题：IE下可以使用window.location或window.location.href；Firefox能使用window.location。解决方法：使用window.location

（6）frame问题:访问frame对象时IE使用window.frameId或者window.frameName来访问这个frame对象.frameId和frameName可以同名。Firefox只能使用window.frameName来访问这个frame对象。另外，在IE和Firefox中都可以使用 window.document.getElementById(“frameId”)来访问这个 frame对象。

（7）模态和非模态窗口问题：IE可以通过 showModalDialog和 show ModelessDialog打开模态和非模态窗口；Firefox则不能。解决方法：直接使用window.open(pageURL,name,parameters)方式打开新窗口。

（8）firefox与IE的父元素(parentElement)的区别:IE：obj.parentElement;firefox：obj.parentNode。解决方法：因为firefox与IE都支持DOM,因此统一使用obj.parentNode。

（9）document.formName.item(“itemName”)问题：IE 使用 document.form Name.item(“itemName”) 或 document.formName.elements[“elementName”] ；Firefox只能使用 document.formName.elements[“elementName”]。解决方法：使用 document.formName.elements[“elementName”]。

（10）集合类对象问题：IE可以使用()或[]获取集合类对象；Firefox只能使用[]获取集合类对象。解决方法：统一使用[]获取集合类对象。

（11）自定义属性问题：IE可以使用获取常规属性的方法来获取自定义属性，也可以使用getAttribute()获取自定义属性；Firefox只能使用getAttribute()获取自定义属性。解决方法：统一通过getAttribute()获取自定义属性。

以上列述了功能问题以及解决方法，另外还有一些外观以及式样问题，如Table操作问题、对象宽高赋值问题、CSS透明等等。这里不在赘述。

2 提交或显示中文时乱码

在项目中经常会遇到中文传参数，在后台接收到乱码问题。那么在遇到这种情况下我们应该怎么进行处理让我们传到后台接收到的参数不是乱码是我们想要接收的到的，下面就是一些认识和理解。

（1）get请求url中带有中文参数，有三种方式进行处理防止中文乱码：

1）如果使用tomcat作为服务器，那么修改tomcat配置文件conf/server.xml中，在

2）前台需要对中文参数进行编码，调用js方法encodeURI(url），将url编码，然后请求。后台接受时，需处理Stringstr=newString(request.getParameter("param").getBytes("iso8859-1"),"UTF-8")；

原因：tomcat不设置编码时，默认是 iso8859-1，即 tomcat默认会以iso8859-1编码接收get参数。以上操作是将参数以iso8859-1编码转化为字节数组，然后再以UTF-8将字节数组转化为字符串。

（2）解决get请求，后台接受中文参数乱码处理的方法(搜索功能带参数）

1）前台获取数据，在js中进行编码处理encodeURI函数采用utf-8进行编码，而在服务器的进行解码时候，默认都不是以uft-8进行解码，所以就会出现乱码。两次encodeURI,第一次编码得到的是UTF-8形式的URL，第二次编码得到的依然是UTF-8形式的URL，但是在效果上相当于首先进行了一次UTF-8编码(此时已经全部转换为ASCII字符)，再进行了一次iso-8859-1编码，因为对英文字符来说UTF-8编码和ISO-8859-1编码的效果相同。

2）后台解码处理

在后台接收参数时候，首先通过request.getParameter()自动进行第一次解码(可能是gb2312,gbk,utf-8,iso-8859-1等字符集,对结果无影响)得到ascii字符，然后再使用UTF-8进行第二次解码，通常使用java.net.URLDecoder("","UTF-8")方法。

两次编码两次解码的过程为：UTF-8编码->UTF-8(iso-8859-1)编码->iso-8859-1解码->UTF-8解码，编码和解码的过程是对称的，所以不会出现乱码。

（3）前后台参数转译的方法

如果以上两种方法都解决不了问题，那么就是参数转译的方法。其原理是：参数传递里用英文或数字标识。在接收到以后根据英文或数字标识再转译成中文。这种方法对规范化的参数是可行的。但会增加代码量。另外，对非规范化的文本参数而言，这种方法尚不适用。

3 前端代码的复用性

（1）前端开发过程中，以下几个问题尤为突出：

1）前端代码的复用性差。大多是复制粘贴似的复用

2）前端代码可维护性差。没有统一的规范和标准，一个人一个风格，即使有的开发团队有这个意识要规范，实施起来也很困难。

3）可读性不强。因为和后端到处是交互。而且有时候边界很模糊，比如：通常我们遵循mvc的思想进行开发，但是，前端有时候，也存在数据的处理。Js的DOM操作，或者对Json数据的再次处理。显得有重复。

4）大部分中小型的公司，可能由于技术或者资金等其他客观原因，使得开发过程根据就不分离前端后端。这就导致了开发效率的降低，质量的降低。付出的代价就是复用性、可维护性差。

5）国内目前大多数的前端开发人员，水平不是很高，而且参差不齐。但是需求量越来越大。因为前端，入门的门槛较低，导致这样的问题比较严重。一般，技术问题很少，有，也就是兼容性的问题了。更多的是：工程类的问题。规范和效率、质量上的矛盾比较尖锐。

（2）如何解决前端复用呢？笔者认为可以有以下两个思路：

1）尽可能原生，并构建本公司的UI库

原生js，html搭建的网页是蛮难维护的，比如一个表单验证，一大堆if else肯定以后维护或者添加功能上面就麻烦很多。

原生的复用也就是代码复用，把代码功能抽象出来，表单验证的功能都类似吧？把功能抽象到方法，比如验证字符串的个数，compare，密码是不是相等，邮箱，手机的验证，正则表达式的验证。

传参验证。每次我只需要定义验证规则和传入input的值就可以。这样一个验证的类，我就把今生所需要写的所有表单验证的逻辑写完了。

项目有两个页面需要验证，不要写2遍if else，调用这个类，传相应参数。拓展类，拓展规则。这样你原来的代码不用改，不需要知道以前一堆jq是什么含义，只需要拓展这个类就可以了。一种好的代码规范就是拓展而不是修改。

2）适度借助力框架

如angular好的实践就是在controller里面不要加太多业务逻辑和dom操作。如果我们想复用就别让它依赖当前controller。angular的指令分装饰型指令和组件。一般复用就要组件不依赖外部环境，这样你才能把这个指令用到任何地方。我们把该指令分离，他需要的数据通过属性传进去，类似 vue和react的props。另外像react就提倡的web components，它的每个部分都是一个组件，当然数据是props传入的，他都给想好了。这个组件就比较好复用了，它维护自身的state，一个组件一个state，两个组件基本上没有任何的耦合。那么复用就好做多了。组件的通信就通过props，子与父组件的通信就需要全局的事件系统了。react复用是做的很好了，但是它没有双向绑定，验证表单写起来较麻烦一点，组件间的通信也很麻烦。所以写react应用的时候，子组件一般就充当渲染组件，上面传什么参数我渲染什么，而且react组件不要嵌套太深，好的实践是扁平化，如果用了redux,就会发现如果嵌套太多组件，state是很难维护的。