UEditor——百度编辑器配置若干

UEditor——百度编辑器配置若干

Hi，UEditor——百度编辑器配置若干

2013-05-09 15:53 by LibraJM, 807 阅读, 0 评论, 收藏, 编辑

最近在用UEditor，好东西嘛大家自然都喜欢用。用的时候碰到了几个问题，大多和配置有关。有些在网上找到解决方案了，有些则没找到，索性终于磕磕碰碰解决了，这里总结下。

编辑器大小

我用的时候（1.2.4.0），大小总是设置为1000的，后来我摸进ueditor_all.js这个文件，改了点东西：

当然我承认这种方式有点土鳖...肯定有更好的方式，不过这里记录下。

路径

其实“路径”是配置的主要内容，这里主要是指“路径不正确”导致编辑器无法正确初始化这样一种情形。

出错提示一般是：“baidu”未定义。

先看两种引用：

<script type="text/javascript" src="ueditor1_2_4_0-utf8-net/editor_config.js"></script>

<script type="text/javascript" src="/ueditor1_2_4_0-utf8-net/editor_config.js"></script>

使用VS的开发版IIS的时候，这两种引用都可以正常工作。but...部署到IIS上后，第二种则被解析为根目录下的，例如：http://localhost/ueditor...当然我承认，这是因为我思维不严谨造成的。

另外一种提示是：“WordCountXXX...”看起来应该是某个内部js未正常引用。这里分两种情况：

如果前面一条路径配置正确（也就是js引用正确），那么是不需要特别配置ueditor_config.js文件中的URL的（默认的可以正常工作）。

否则的话，仍然有以下两种情况：

window.UEDITOR_HOME_URL = 'ueditor1_2_4_0-utf8-net/';

window.UEDITOR_HOME_URL = '/ueditor1_2_4_0-utf8-net/';

当然，在开发版IIS上仍然可以正常工作，但是部署到IIS上就...这里我不得不说，注释部分有点误导了。

图片上传

首先要做一件事情（网友经验），否则图片上传会失败。就是找到图中文件（imageUp.ashx），把选中的一行删除。

然后在下图的文件中配置路径（上传的路径），可以依赖于该文件的相对路径。

然后呢，上传的照片总该在编辑器里面正常显示的吧？在ueditor_config.js中配置显示路径：

配置安全性

默认情况下，ASP.NET安全性会导致编辑器不可用（提交），所以这里也需要配置下（网友经验）。但是，如果正式发布的话，这里应该使用额外的代码来保证提交的内容安全。

首先，在web.config下面配置，以禁用检查：

当然，在4.0模式下面，这个行不通，所以要继续配置以下内容：

<httpRuntime requestValidationMode="2.0" />

然后，在页面中声明下，我确实不需要检查：

其他路径配置问题

“当命中要点的时候，有些问题会接二连三的被解决”...我今天终于感受到了...前面几个路径配置的问题，让我想到前段时间我没能解决的一个问题。那时我打算使用一个脚本文件来包含所有其他的脚本文件的引用。然后，在页面上我只需要引用那个用来包含其他引用的脚本就可以了。原理是在文件中加入“document.write()”这样的语句以输出一些引用，不过总是不成功。

我当时的写法是这样的：

document.write('<script src="~/Scripts/JSefect/floatmenu.js"></script>');

好吧，直到现在我才注意到，“~”这个符号，这种方式太.net化了，如果想引用跟路径，只需要“/”。于是我去除了“~”，所以一切工作正常了。

...

应该会碰到更多问题。

 

 

分类: 聚沙塔

标签: UEditor, 百度编辑器, ASP.NET

谈谈如何应对软件开发中的需求变更

令人烦恼的需求变更

    在软件开发中，大家都会遇到过这样的问题：客户的一个新想法，就推翻了之前与客户经过再三讨论而确认定下来的需求。如果是功能性需求变更还会让人容易接受一些，毕竟功能性需求不实现的话，是会大大影响到软件产品的质量。但是一些非功能性的变更会让人很头疼，许多是看起来无关痛痒的、鸡毛蒜皮的变更，却是极为令人无语和无奈，甚至是烦恼和厌恶的。

 

    （1）什么是软件需求？

    在IEEE中，软件需求的定义是：用户解决问题或达到目标所需的条件或功能。一般包含业务需求、用户需求、功能需求、行业隐含需求和一些非功能性需求。业务需求反映了客户对系统、产品高层次的目标要求；功能需求定义了开发人员必须实现的软件功能。所谓非功能性需求，是指为满足用户业务需求而必须具有除功能需求以外的特性。包括系统性能、可靠性、可维护性、易用性和对技术和对业务适应性等。其中最常见的是软件界面、操作方便等一系列要求。

 

    （2）非功能性需求变更的特点

    让我们从客户角度和开发人员角度去看看非功能性需求的特点。首先，有些非功能性小需求从客户角度看起来工作量不大，但是实际上开发人员要耗费比较长的时间去完成这些小功能。其次，许多非功能性需求，如界面美观、操作方便等都是客户头脑一热、或领导一拍脑袋就部署下去的需求，往往是原来在需求分析阶段所没有注意的内容。

 

    其实，非功能性需求是常常被轻视，甚至被忽视的。原因是非功能性需求描述很困难，它很难像功能性需求那样，可以通过结构化和量化的词语来描述清楚。在描述这类需求时候，我们经常采用软件性能要好、操作要方便、软件界面要美观大方等较模糊的描述词语。例如，易用性就同时涉及到美工和UI界面、人机工程、交互式设计、心理学、用户行为模式等内容。这类描述词语都是脱离了软件的执行环境，是对人和相关的场景的描述，因此很难体现到软件架构设计和具体的实现中。

 

     国内的很多软件公司，对于这种情况趋之若鹜，认为是负担，影响软件公司的工作安排，工作量以及工作进度，直接导致了软件公司的效益，几乎是很多软件公司的最大隐患，因此我们如何认识、对待这个普遍存在的问题就成了软件公司以及员工需要解决的问题；

 

1) 首先，要从心理上彻底根除对需求变更的恐惧，从认识上明确需求变更是软件开发过程中不可缺少的部分，从方针上明确需求变更的存在性和必然性；

a) 从软件公司角度，认清自身存在的不足， 客观面对需求的变更

b) 从职员角度，提高本身的业务和技术能力

 

2) 从技术角度上使需求变更的处理简单化，明确化，增加可维护性；

a) 使用更好的技术手段，设计更灵活以用来适应更多变的需求；

b) 使用更完善的软件工程的理念，让软件各个步骤细化，更易维护和修改；

c) 使用完善的测试流程，最大的降低需求变更带来的软件风险；

 

3) 对需求变更进行有效的管理，让需求变更可以规范化管理，做到有效的处理需求的变更，用有限的资源获得最大的效益；

a) 软件的初期，就要考虑最大限度的减少将来可能存在的需求变更

b) 需求的控制，减少需求的来源，过滤不合理的需求

c) 文档化管理，有备可查，有据可依；

d) 合适的公司体制和运作，找到一条适合自己公司发展的运作体制和管理模式；

 

    可能大家觉得上面说的话有些空，那么我就从技术角度上再具体的谈谈。

    就像刚才说过的，需求变更是必然存在的。从技术的角度来降低或避免需求变更给我们带来的影响就显得极为重要。

 

    1. 设计之初，充分理解需求，更好对需求进行整理和规划，预测可能变更的需求。

需求难做，业务难做，非功能性的需求变更更是难做。所以当我们在收集了用户需求后，不仅仅是简单的分类，然后按部就班的开发，而是要深入挖掘需求，一些看似固定业务的需求，可能由于业务的变更而使得你的系统不能使用。我们要做的就是拆分需求，把一些可能会发生变化的需求拆开，改成工作流程可配置的。就像面向过程转向面向对象的那样，面向过程是死的，而面向对象重新组合后，就特别简单。

 

    就说说我们刚做的这个收银系统吧，用户要求结账时，要打印小票，并自动打开钱箱。这就是最最原始的需求。但是我们最终把它做成了这样：打印机是外部设备，可以增删和配置；打印次数可配置；打印样式可配置；打印时，要判断打印机状态，非正常状态要给出各种提示（不一一列举）；钱箱可以自动打开，也可以手动打开。另外还设定了许多功能配置：如禁用/启用全部打印机，禁用/启用某个打印机，是否打印订单小票，是否自动打开钱箱，是否显示错误提示信息等等（如图）。

    我们把这个固定的需求，拆分成可配置的，这样就把这个需求可能的变更已经分析的差不多了。不论它怎么变化，我们的应对都会变得从容。就在前2天部署的时候出现问题了，打印机是新买的，不只是什么原因，在打印多个换行之后，就会失败，不能继续打印。这个问题是我们所料不及的，因为我们测的我们这里的所有打印机，都完美打印，而新买的也是同品牌，同型号的打印机。最终分析出这个问题后，我们不用更改系统，只要修改一下小票样式配置，就可以完美打印了。

 

小票样式设定（图）：

硬件设置（图）：

单个打印机设置（图）：

功能设置（图）：

 

 

    2. 系统完成之后，客户再提新需求后，要分析这个需求的深层次含义，分析客户要的到底是什么。对于一些需求，如果适合于大部分客户，而且改动很少，就可以完成，那么可以在下个升级版本中集成。而对于某些非功能性的需求，改动太大，或者基本的核心功能都需要更改的话，那么就不要先去急着实现，而是放置起来，等待系统需要进行大的升级或者重构时，再考虑添加。而且要防止客户滥用提需求的权力，对于一些不合理的需求，还要去引导客户，让他们理解这个功能的不合理的地方，从而重新修改需求或者放弃。