ASP

在ASP.Net中對各個WebForm控制項引入以前沒有的EnableViewState屬性。這個屬性究竟有什麼用。我們知道對於WebForm而言，其代碼是在伺服器端的，以處理用戶端的請求。當使用者通過瀏覽器瀏覽網頁的時候，會對網頁進行某些操作，比如開啟新連結，或單擊某個按鈕。在ASP中，這些是通過指令碼語言對其進行處理，之後再傳遞給伺服器端。但是在ASP.NET下，由於採用了code

  public void makeht(string url, string makedhtm)    {        HttpWebRequest request = null;        HttpWebResponse response = null;        Stream stream = null;        StreamReader reader = null;        request =

ASP2HTML WITH TEMPLET我希望大家看到該標題就能讓想象到它的功能：1，WITH TEMPLET意思是，產生的頁面架構將採用某個已設定的模板，在此之前我的一篇教程中介紹過，希望各位在看本教程之前對ASP採用模板應熟悉下。（當然，不看也沒有問題，本教程同樣會提及精華部分的：）具體參考：http://www.cnbruce.com/blog/showlog.asp?cat_id=26&log_id=474 2，ASP2HTML。不要我再說ASP轉變成HTML的好處了吧，呵呵，

ASP.NET 如何擷取地址欄URL地址？看下面的實現方法：第一種： http://www.liehuo.net/liehuonet/default.aspx Request.ApplicationPath: /liehuonet Request.CurrentExecutionFilePath: /liehuonet/default.aspx Request.FilePath: /liehuonet/default.aspx Request.Path:

gSOAP是一個跨平台的實現SOAP通訊的開原始碼庫。這是我對這個開源項目到現在為止的不完全瞭解。所以能介紹的就是這些了，可能還存在錯誤。因為和同事在弄一個項目，要在用戶端用C++和ASP.NET發布的WebService通訊。所以這幾天開始研究這個庫。昨天實現了其例子程式的幾個通訊，因為自己對ASP.NET也是一知半解，所以只能把和ASP.NET發布的WebService通訊留到今天。晚上回家小查了一下ASP.NET的簡單應用，雖然遇到一點問題，還是建立起了一個ASP.NET的伺服器。 

FCKeditor是一個專門使用在網頁上屬於開放原始碼的所見即所得 (WYSIWYG)文字編輯器。它志於輕量化，不需要太複雜的安裝步驟即可使用。它能在asp、 asp.net、PHP、JSP等多個平台下使用，並且支援大部分瀏覽器，所以在它出現的6年時間裡，成為了最流行的文字編輯器。　　隨著技術的發展，很多更新更方便的東西為開發人員提供了更大的便利。在這種情況下，FCKeditor團隊推出了一個FCKeditor的重寫版本——CKEditor。　　新版本的CKEditor載入速度更快、更方便使用，

剛剛接觸了幾天ASP.NET MVC架構，發現它和原來asp.net的web form模型相比，產生的Html代碼更加整潔了，沒有了viewstate。前台頁面中的代碼有點像asp，但是可以把邏輯處理部分寫在其他的代碼檔案中，前台只負責展現。MVC架構的工作流程（摘自Scott

剛剛學了幾天的MVC架構自己也試著做了一個留言本的樣本小程式，初步的瞭解了一下MVC架構的功能。通過這個樣本瞭解了MVC架構中的幾個有用的東西。1、HandleErrorAttribute（MVC架構內建的分頁錯誤處理Filter）這個內建的處理錯誤的功能很簡單，只能在當頁面出現錯誤的時候把錯誤資訊收集起來，並顯示友好的錯誤提示的View(需要在web.congfig中配置是否啟用友好錯誤提示的customErrors節點)。在用ASP.NET MVC

      ASP.NET MVC架構出來也快三年了吧。從它剛誕生的那一天起，我就開始在關注它了。但是一直沒有找到一個基於ASP.MVC架構下的比較好的CMS系統。在ASP.NET Web Form下有DotNetNuke，在PHP下有WordPress。當時我就在想，如果我要在ASP.NET MVC架構下開發一個CMS系統，採用WordPress的方式也許更容易實現些。今天發現了Orchard，它像極了WordPress，看來英雄所見略同，哈哈。      

　　前兩天看過bestcomy 的關於大檔案上傳的系列文章真是受益匪淺，對ASP.NET中上傳檔案的方法又有全新的認識，這比原來簡單的運用SaveAs()的方法不知要高明多少。認識提高了，新的想法就來了。不知道AspnetUpload組建能不能支援斷點續傳。不過將伺服器上的檔案上傳到資料庫的過程我想是可以實現斷點續傳的。將大檔案上傳到資料庫的基本思路是：分次讀取檔案到緩衝區，利用使用 SQL Server 的 UPDATETEXT

View層-->View層的JS function-->Controller-->返回JSON資料-->View層的JS

在開發中編寫的js、css發布的時候，往往需要進行壓縮，以減少檔案大小，減輕伺服器的負擔。這就得每次發版本的時候，對js、js進行壓縮，然後再發布。有沒有什麼辦法，讓代碼到了伺服器上邊，它自己進行壓縮呢？ 有兩種辦法：第一種，在css、js請求到來的時候讀取一下相對應的檔案，進行壓縮後返回。此方法可以通過在Global.asax的Application_BeginRequest的事件中，進行處理，也可以在web.config中註冊一個httpHandler進行處理。第二種是在程式啟動的時候，對全

Asp.net WebForm中應用Jquery EasyUI Layout 按照EasyUI文檔中的樣本，編寫layout代碼： <body class=”easyui-layout”>         <div region="north" border="false" style="height:60px;background:#B3DFDA;">north region</div>     <div region="west"

問題由來最近在研究適合團隊開發的web架構解決方案，該架構即要適合分工協作又要有一定擴充性，適合不同的資料庫需要，因此我查閱了一些資料，初步構想出了一套架構，請各位多多指教。 探索web開發架構最經典莫過於三層架構，展示層、邏輯層、資料處理層。資料訪問層：其功能主要是負責資料庫的訪問。商務邏輯層：是整個系統的核心，它與這個系統的業務（領域）有關。展示層：是系統的UI部分，負責使用者與整個系統的互動。理想的狀態是展示層不應包括系統的商務邏輯。這些是經典的解釋，如果要適合不同的資料庫則需要加入原廠模

引言 URL 重寫的常見用法 請求到達 IIS 時將會發生什麼情況 實現 URL 重寫 構建 URL 重寫引擎 使用 URL 重寫引擎執行簡單的 URL 重寫 建立真正“可刪節”的 URL 結論 參考資料 引言 讓我們花點時間來看一下網站上的一些 URL。您是否發現一些類似於

• 在處理請求時可以引發事件。 • 允許任意數量的 HTTP 模組處理所引發的事件，這與 IIS 的 ISAPI 篩選器相似。 • 將呈現被請求資源這項任務委託給 HTTP 處理常式，該處理常式與 IIS 的 ISAPI 擴充相似。 與 IIS 一樣，ASP.NET 引擎在請求的有效期間內將會觸發事件，通過發訊號來表示其處理過程從一個狀態改變為了另一個狀態。例如，當 ASP.NET 引擎首次響應請求時，BeginRequest 事件將被觸發。接下來觸發的是

通過 System.Web.HttpContext 類的 RewritePath() 方法，可以在 ASP.NET 層級實現 URL 重寫。HttpContext 類包含有關特定 HTTP 要求的 HTTP 特定資訊。對於 ASP.NET 引擎收到的每個請求，均為該請求建立一個 HttpContext 執行個體。此類具有如下屬性：Request 和 Response，提供對傳入請求和傳出響應的訪問；Application 和

&#8226; Dispose()。當請求已完成並已發送回 IIS 時調用此方法。您應當在此處執行所有最終的清除操作。 為了便於為 URL 重寫建立 HTTP 模組，我將從建立抽象基類 BaseModuleRewriter 開始介紹。此類將實現 IHttpModule。在 Init() 事件中，它將 HttpApplication 的 AuthorizeRequest 事件綁定到 BaseModuleRewriter_AuthorizeRequest

<RewriterConfig> <Rules> <!-- 產品製表者規則 --> <RewriterRule> <LookFor>~/Products/Beverages\.aspx</LookFor> <SendTo>~/ListProductsByCategory.aspx?CategoryID=1</SendTo> </RewriterRule> <RewriterRule&