浅谈ASP.NET页面生命周期(控件)
ASP.NET的优点我说过很多次了，也就是各个控件独立负责自己内部的逻辑，这是一个好事情，因为它解决了原本ASP处理逻辑耦合度高的问题。然而这是需要代价的，那就是引入ASP.NET页面生命周期，随着控件的多层嵌套，应用的复杂度增加，我们再次陷入泥潭！
其实这个文章题目我两个月前就写下了，可是一直没想写完它，直到今天我在这个泥潭中泡了几个小时，于是决定先从泥潭中跳出来把文章写完，再跳进去继续解决问题。问题是这样的：
1. 使用MS AJAX 1.0 Beta2 + 2.0 CTP新建一个项目，同时在Bin中放上Beta2的AjaxControlToolkit.dll。
2. 扔上一个Accordion，放置几个AccordionPane，设置一下CssClass。
3. 在Page_Load中使用Page.LoadControl加载一个UserControl，然后添加到页面上。
4. 接着发现UserControl内的控件无法正常触发事件，陷入泥潭中……
首先要说明，如果仅仅做第3步那个UserControl肯定正常运作，那意味着问题出在ScriptManager或Accordion中出现了问题。
想知道到底是什么出问题了吗？先听我说说这个ASP.NET页面生命周期的问题吧。
由于ASP.NET页面生命周期按阶段划分，任务在不同阶段按部就班完成，所以我们的每一个操作都是阶段相关的，有些操作仅能在特定的阶段操作，有些操作在不同阶段执行会导致不同的结果。当然，MS希望尽量消除这些阶段间的差异，例如让一个操作在尽可能多的阶段中都能执行，并且尽可能减少在不同阶段中操作引发的不同结果。然而这不可能完全做到，例如我们都知道ViewState读写限制为仅能在某些阶段进行，于是依赖于ViewState的控件属性也就因此受到同样的限制。
控件属性读写受阶段限制，这很好接受，对吧？因为这仅仅是一层依赖关系。顺着依赖关系推广出去，情况会变得越来越复杂，限制的原因埋藏得越来越底层，接着我们发现复杂性这一问题在ASP.NET这种结构良好的体系中出现了，而消灭这种复杂性的银弹还没被发明。
作为控件或组件的开发人员，我们当然有义务消除阶段差异，让下游的开发人员面对更低的复杂性，而且我们也确实尽力去做了。控件的每一层封装，都包含着这种努力，并向上承诺尽可能低的阶段差异。然而为了让控件看起来简单易用，我们不可能将这些差异完整地记录在文档之中，我们尝试去隐瞒细节，控件被层层封装时我们都这样做。底层文档没告诉我的差异，我当然也没必要写到这一层的文档上去；底层文档提及了的差异，我尽力弥补了，即使弥补得不太好，也不写到这一层的文档
相关文档：
在Web编程过程中，存在着很多安全隐患。比如在以前的ASP版本中，Cookie为访问者和编程者都提供了方便，并没有提供加密的功能。打开IE浏览器，选择“工具”菜单里的“Internet选项”，然后在弹出的对话框里单击“设置”按钮，选择“查看文件”按钮，在弹出的窗口中，就会显示硬盘里 ......
在GridView中我们可以直接添加一个CommandField删除列来删除某行信息。但为了避免误操作引起的误删除，在删除操作者让操作者再确认下，完后再进行删除。
首先我们给我们的GridView 添加一个模板列，如下：
以下是引用片段：
＜ASP:TemplateField HeaderText="Delete" ShowHeader="False"＞
＜ItemStyle ......
我們在開發網頁應用程式，時常需要去解析網址(Request.Url)的每個片段，進行一些判斷。例如說 "http://localhost:1897/News/Press/Content.aspx/123?id=1#toc
"，我們想要取得網址裡第一層目錄� ......
在Asp.Net2.0中，button控件添加了onclientclick属性，通过这个属性可以先执行客户端脚本，然后根据返回值再执行服务器端脚本。
在工作中遇到这样一种场景：点击一个button后，显示一个gif动画图片，然后再执行服务器端的脚本。gif动画图片放到一个隐藏的div中，点击button以后，div会现身，显示gif图片。
问题是：在fire ......
有时会碰到
System.IO.Directory.Exists("\\server11\jqb")
总是返回false,说路径不存在，事实上它是存在的，引起这个问题的原因是由于window的权限问题
。
解决方案如下：
1。在aspx本机和欲访问的远程主机（如 server11）分别建一个名称（如 jqbsystem）和密码（如
1234）一模一样的windows帐号
2。在web.config� ......
