Archive for 'Web Development'

针对javascript，对设计模式的思考。

JAVA中的一些特性，可以说都很好的匹配了这些个设计模式，并且，设计模式有很多好处。

但是在javascript中，寸土寸金，代码的量也是一个非常重要的考虑目标。代码小1K，下载速度就快一些，用户体验就好一些。

那么如何在javascript中，来实际应用这写设计模式。

像taobao小马同学，提出了为应用者，只提供工厂方法和工具方法。

这个思路很好，但是有个问题，在系统内部，我们又如何来团队合作？如何来增加扩展性？

都知道，JS里new一个对象的开销会比较大。这些设计模式多出了很多中间对象，我们该怎么办？

我还没想好，很乱，等晚上有空了静静思考下。哈哈

设计模式，学习笔记，二

上周5、6、7都参加了设计模式的培训，3天有点量大了。其实是只起到了提纲挈领，开阔思路，阐明概念的作用。我还没有深入理解设计模式。

好了，说说程序设计的思想吧。

抽象于实现分离。在设计系统的时候，通过对角色、职责的抽象，根据业务逻辑，规划属性和行为。遵循几个基本的原则：但职责原则，松偶合原则，依赖接口不依赖实现。联想一下，这好比UCD中的用户流程–》site map–》线框图，有些类似，自顶向下的设计。

利用好面向对象语言中的多态。所谓多态，

var a = new o1();
fucntion x(obj){
obj.do();
}
x(a);
o1可以是一系列的有相同接口的类，他们的实例可以用相同的方法调用，在系统运行时，动态的决定哪个需要对象，以完成不同的工作。

观察者模式，专门的一个对象，侦听某个条件，条件改变则做出响应，调用其他对象做出相应改变。

状态模式：把每个状态做为一个对象。有一个状态调用者，也是对象。那么现在设置一个初始状态对象。之后，客户不需要切换状态，直接调用状态执行行为，状态的切换由状态对象自己来切换。其实也是利用了多态。

命令模式：动态绑定的时候，用命令的模式，例如用户键盘输入的字符串，系统生成的字符串等。也可以是直接以对象为命令。

 另有中介者、代理、门面模式。我觉得都可以归结为中间件，只是职责不同。

其实很多我们在我们自己写的代码中都存在，但是没有做动态绑定，没有做单职责。这个在团队开发的时候，带来了麻烦。A要理解B写的代码变得很困难，如果采用单职责的原则，并且使用公认的设计模式，让后人更加容易理解代码，更加容易维护、扩展。代码即是文档。

How to make Ajax work for you

我直接做链接了

http://www.slideshare.net/simon/how-to-make-ajax-work-for-you/

设计模式，学习笔记

这段时间参加培训，内容是设计模式。具体什么是设计模式，究竟有哪些设计模式，大家GOOGLE一下估计都有。

设计模式其实是一些被公认的解决方案，在团队合作开发、可扩展性、松偶合性、降低复杂度方面有两好的表现。

课程的一开始，老师就说，设计模式并没有对错，只有适合与否。很多的书中，都讲哪个模式怎么怎么好，要么说哪个模式怎么怎么不好。其实应该辨证的来看。。。。哇卡卡又上升到哲学了。还是言归正传。

在程序设计的过程中，面向对象的思想常常被误解，并不是用了类和实例就是面向对象了。面向对象是整个系统以行为驱动的，高度的封装，松偶合。其实说来说去就是这么点，关键在于这个高度高到什么程度。这并不仅仅是统一接口这么简单，对于各种实例的管理、创建都有一个中间件。这个中间件在各个设计模式中有不同的名称，例如：工厂类、虚工厂类、build、适配器等等。

这两天的学习，和同学们的讨论，得出了一些共识。

1. 一切模式的根本是工厂模式。
2. 采用不同的模式，很重要的目的之一是降低维护、交接、沟通成本
3. 设计程序的时候，把结构事先设计好，免得再用这些个中间件来包装LJ代码。

我想到了我们的AE框架，当我还是一个懵懂的少年，经过成长，经过和TBRA的融合，经过和5年前的JS代码的合并，AE框架已经是有着多样接口，多样调用方式的一个框架，其实是不利于使用的。接下来我要做的一件事情是把这些东西封装一下，让以后的产品都更加适合团队开发。

最后，我自己认为，其实在业务模块之间，或者是不同产品之间，设计模式尤其重要。而在一个模块内部，硬编码可以降低开发成本，甚至由于代码量比较少，硬编码还能方便后人的阅读和理解。

非常欣赏老师的一句话：代码即是文档。（绝对经典，体现了设计模式的重要性）

不错的BLOG，收了，FED们有兴趣可以去看看

http://www.web-development-blog.com/

前端开发工程师，该掌握哪些技能？该深入掌握什么知识？

近两个月，一直在想，前段开发工程师，究竟该掌握哪些技能？
和taobao的同事聊了聊，都有共同的感想，目前前端开发刚刚兴起，还没形成学科。也许算在计算机与应用之内吧。

想了想，目前网络上流行的也就是要JS、CSS、XHTML、AS等等，外加对设计的各种方法的了解。似乎是一个很奇怪的位置。假设对上面的技术都达到了精通，那么就到了颠峰吗？这个颠峰似乎比其他学科要容易许多。

我想，前端开发，如果纯走技术路线，是否可以在“用户对信息检索所采用的方式”这点上创造发明？人们最终期望通过什么样的方式远程交流？我们可不可以起一个课题，在网络速度爆发的前夜，创造出全新的信息获得方式？（太大了，不是一门科学能办到的）

我想，前端开发，不应该只是各种效果、功能的实现者，这个境界在5年内可以很好达到。也许应该借鉴一下计算机各学科的内容，也许应该归结在人机交互这个学科里。

在些写之前，我还是一团疑惑，等我写下这些内容，我自己的思路也整理得比较清楚。我应该先去通览一下计算机的各个学科到底是些什么内容，再总结一些必须扩充的知识面，然后就是学习，为将来5年10年甚至2、3十年做好续航的准备。

书到用时方恨少啊。我是学电的，只学了点计算机的皮毛，凭着兴趣做了这行，发现要深入研究还是得回到大学去。图书馆是个好地方啊。

input, textarea, option, value问题.

var get = YAHOO.util.Dom.get;例如<textarea id=”xx”> <>&lt;&gt;</textarea>
这时候, var a = get(‘xx’).value;   
这个a中的内容是<><>  ，就是说&lt;&gt;被转义了。 同样，input option中的value有同样的问题。

如果 var b =  get(‘xx’).innerHTML;
这个b中的内容是 &lt;&gt;&lt;&gt;  ， 就是说，<>被转义了

根据上面的情况， value中出现<>&lt;&gt; ， JS是无法区分是HTML转义符还是真的<>。

具体问题：在HTML编辑器中，用户在所见即所得情况下直接输入<>会被转义， 而编辑器生成的HTML代码是不转义的（HTML嘛，转义了就不是HTML了）
那么，当用户编辑这些内容的时候， 从数据库中直接取出， 放入textarea中，编辑器是无法区分真的HTML还是用户期望展现的<>。

再具体点就是，存入数据库中的数据是这样的&lt;font size=+2&gt;a<strong>b</strong>&lt;/font&gt; 
那么当用户用编辑器存储这些内容的时候，变成了<font size=+2>a<strong>b</strong></font>完了， 编辑器失去意义了。

解决方案一： 建立一个隐藏的div, 编辑器初始化的时候， 从DIV中取数据。
但是这样的话， 一来DIV中的HTML情况不可预测，可能造成页面错位或者脚本错误。二来实现方法变得复杂。

观察了几款编辑器，都没有做这样的处理，就是说我刚开始冒出来的点子肯定是很烂的。

后来上taobao去晃了晃，发现是对写入textarea中的内容做了如下转义。把&lt;> 转成 &amp;lt;&gt;
问题迎刃而解。原理是对内容进行了一次HTML转义，由于value对转义的处理机制，真的标签会被还原， 而&amp;lt;这样的内容被还原成了&lt;

另外，在input option的value也可以做同样的处理。

第二节：velocity向javascript传输内容。我另开个帖子吧， 嘿嘿。

好了，主要内容结束。

讲个附加问题， 就是互联网一直存在的用户在表单中输入HTML的问题， 一般来说，网站都不会允许用户输入的HTML展现在前端。
我推荐的处理方式是， 用户输入什么，就向数据库存什么，不做转义，保证原始数据的真实性。
在输出的时候针对script, value, innerHTML做不同的转义输出。 情况各有不同。

这个转义相信很多网站都做了， 我是在想， 是否在velotity或者JAVA中就事先做好取数据的接口。通过三种不同的方式来取，或者在生成HTML代码的时候，根据所在标签位置不同，架构直接对内容进行转义，就不要每个地方去转一下了。