谦卑的程序员

　　这是关于ASP.Net常被问到的一个问题，很老很老的概念，但也是一个比较容易一知半解的问题。自问了一下，似乎揣着明白说不清楚，于是做点功课整理一下。

首先，为什么会有Web服务器控件、Html服务器控件和Html控件

　　Html控件无需多说，最常用的控件，ASP时代的唯一选择，世界开始的时候它就在那。当微软推出.Net后，为了提供ASP.Net Web Form开发以和Win Form开发相似的开发体验，推出了Web服务器控件（Server Control），又称ASP.Net服务器控件。而Html服务器控件（Html Server Control），则可以看做是为了向下兼容，便于原本基于ASP系统的移植而推出的一种介于Html控件和Web 服务器控件的权宜产物。

Web服务器控件、Html服务器控件和Html控件的区别

• Html控件的标签：<input id=”Button” type=”button” value=”Button” />
• Html服务器控件的标签：<input id=”Button” type=”button” value=”Button” runat=”server” />
• Html服务器控件其实就是Html控件的基础上加上runat=”server”所构成的控件
• Web服务器控件的标签：<asp:Button ID=”Button” runat=”server” Text=”Button”/>
• Web服务器控件会根据情况在浏览器端产生一个或多个对应的Html标签。

• Html服务器控件位于System.Web.UI.HtmlControls
• Web服务器控件位于System.Web.UI.WebControls
• Web服务器控件与Code Behind的Class文件相结合，提供了包含属性、方法和事件的完整对象模型。

• Html控件不能在服务器端控制，只能在浏览器端通过javascript等脚本语言操作。
• Html服务器控件设定了runat=”server” 属性后，页面对象会将该控件载入控制器，服务器端的代码就能对其进行控制。
• Html服务器控件在页面执行完毕后会被转换成Html标注，然后当成字符串流发送到浏览器端，浏览器端的脚本能够进行操作。
• Web服务器控件的操作则是由页面把Form发回服务器，然后完全由服务器端代码处理。

• Html控件的事件处理发生在浏览器端，除非Submit，否则不会发生Postback
• Html服务器控件的事件处理发生在浏览器端。
• Html服务器控件如果要Postback到服务器端，调用服务器端的方法，需要添加onserverclick之类的事件。
• Web服务器控件部分默认为AutoPostback，或者可以设置AutoPostback。

• 在产生Postback或是重新生成页面时，Web服务器控件自动保存状态到ViewState。
• Html控件和Html服务器控件需要自己编码实现。

Web服务器控件、Html服务器控件和Html控件的优缺点

• Html控件和Html服务器控件需要编码以保持浏览器兼容。
• Web服务器控件能够检测浏览器的兼容性，保持表现的一致。

• Html服务器控件通过为Html控件添加runat=”server”以实现ASP程序的移植。
• 将ASP程序移植成使用Web服务器控件的ASP.Net程序相当于重写新的应用。

• Html控件和Html服务器控件是标准控件，能够用浏览器端脚本语言操作。
• 使用Web服务器控件提供的对象模型，能够得到和Win Form类似的编程体验，而且无需再学习不同的脚本语言。
• Web服务器内部的代码并不开放，你无法获得比较直接的控制。

小结

　　个人认为，Html服务器控件作为一个过渡的实现，虽然能够兼顾浏览器端和服务器端，终究是一个奇怪的存在，尽量少使用为妙。从微软的角度，良好封装的Web服务器控件提供了大量的便利，同时Web Form和Win Form开发模式的差异使得相互的经验能够互通，当然是多使用Web服务器控件为好。不过Web服务器控件的缺点是占用服务器资源，页面Postback过多（Ajax啊Ajax）。所以现实是存在的就是合理的，Html还是要会地，Javascript当然是要好好学地，Web开发各种奇奇怪怪的标签共存于Page中的场面短时间内是不可能消失地。

参考资料

《html控件、html服务器控件和web服务器控件的区别》 （原出处不详，请Google）
<Difference Between ASP.NET Server Controls,HTML Server Controls and HTML Intrinsic Controls>

按照来源区分，可分为兼容MU的Wordpress插件和针对MU开发的插件

　　Wordpress MU是Wordpress的多用户版本，因为程序结构的关系，Wordpress MU并不一定能兼容Wordpress的插件。这里我们谈到的兼容，是指无需做任何修改即可在MU中直接使用的Wordpress插件。针对MU开发的插件中，分为在原Wordpress插件基础上修改的和针对MU全新开发的两种。

按照作用范围区分，可分为全局插件和分站点插件

　　Wordpress中按照影响范围将插件分为两类，全局的插件和针对单个站点的插件，分别存放在不同的目录。

　　/wp-content/mu-plugins/ 目录下存放的是全局的插件。此类插件一般属于比较简单的插件，没有插件目录，而只是由一个php文件组成。上传后该类插件后不会出现在各个博客后台的Plug-ins菜单里，而是出现在Site Admin菜单里（必要的话）。此类插件无需逐个博客激活插件，默认就已经自动调用。

　　/wp-content/plugins/ 目录下存放的是分站点的插件。此类插件上传到后，需要用户手动在Plug-ins菜单的管理面板中启动（前提是管理员为该用户开启了该权限）。用户启用该插件仅影响该站点，而不会影响其他站点。

Wordpress MU插件的管理

　　如果是单文件的简单插件，则直接作为全局插件上传即可，无须也无法做任何管理。（有一个为含目录的插件创建调用的文件并作为全局插件的方法，查询无果，略过）

　　对于分站点的插件，如果管理员不想把启用和禁用插件的权限下放给用户，而想统一地为特定的博客启用和禁用插件，可以使用Plugin Commander或者WPMU Plugin Manager插件（两者孰优孰劣还没来得及比较）。

Wordpress MU插件的选择

　　首先当然是选择针对MU开发的插件，相当部分在WP平台上广受欢迎的插件都有针对MU的修改版本，既经受过时间的考验而且在使用习惯上能够得到延续。无论有无WP的经验，首先查询WP的相关插件，然后查询在MU平台上是否有衍生品是不错的方法。

　　当然针对WPMU全新开发的插件也有其优势，就是完全定制，在跨博客的兼容性方面会有比较全面的考虑。WPMU的官方站点的插件列表在这里。可惜的是数量与WP相比相差太多，活动也并不十分活跃，反倒是有相当一部分不错的插件被放在了需要付费的Premium区，当然这个WPMU的定位有关。

　　至于那些默认兼容的插件，需要注意的就是不会有任何跨站点兼容的支持。比如通过Tag获取相关文章，其影响范围只能限于单个博客，在不修改的前提下想跨博客建立关联是不可能的，这很显而易见。

兼容性的问题

　　因此Wordpress的部分简单的插件虽然可以默认兼容到Wordpress MU，但是还要谨慎对待。如何辨别是否兼容，区分的尺度方面，比如涉及到数据库的表，文件目录的操作，由于程序结构的关系，不修改恐怕是难以兼容的。其它的无非是多查询现有的资料以及自己尝试了。

　　即使功能运行正常，在比如升级、创建新用户、创建新博客时还是将插件先关闭为好，同时要注意不同插件之间冲突的可能。