2020年7月以來，持續對 UfqiLong 有福常在 進行升級改進。
改進過程中遇到之前不曾見的問題，在使用 GTAjax進行異步遞交 有福常在UfqiLog 的文章内容時，有隨機性地出現遞交失敗。進一步的跟蹤發現，儅點擊遞交后，GTAjax接管了表單遞交動作並觸發了進度顯示並進行讀秒操作。
但是，詭異的是，GTAjax在後臺並未真的將遞交發送給服務器端後臺。於是我們決定對 GTAjax開啓 debug 模式，進行深入分析，爲何之前不曾有這樣的問題，爲何問題會是隨機性出現，而又爲何，儅第一次遞交失敗后，第二次原樣操作，卻能成功？
帶著這些問題，我們準備深入分析一下。開啓 GTAjax的debug模式相對簡單，在 運行時參數裏:
var myGTAjax = new GTAjax();
myGTAjax.set(‘isdebug’, true);
這樣即可打開 GTAjax 的過程數據輸出，從而觀測到整個通訊過程。通過分析debug日志，問題很快鎖定到 postForm.submit() 這個節點上。
也即，在使用 ForceFrame 模式進行表單遞交時，依賴 JavaScript的 HTMLFormElement.submit() 這個方法進行最終的數據遞交。
這個是 W3C、HTML DOM和 JavaScript等標準組織封裝好的方法，無法進一步地往下拆解。問題就轉化為爲何 submit() 遞交失敗呢？通過進一步地分析，我們發現在 GTAjax 接管真正的 HTML Form表單時，通常會通過 _DFM_F 方法將 onsubmit 返回一個 false，從而阻止正常的遞交，然後GTAjax 再開展一系列的準備動作之後，再遞交 postForm.submit() 進行遞交。
詭異的地方在於，Google Chrome、MS Edge等瀏覽器，之前即便對HTML Form設置了 _DFM_F， 調用 postForm.submit() 時並不會受影響，而且儅 GTAjax 通過 _RGT 方法進行初始化設置之後再次調用 _DFM_F ，然後再次 postForm.submit() 時，卻是可以通行過去，如預期地進行與服務器端的通信。
我們推測，可能是近期的Google Chrome和MS Edge瀏覽器的升級，增加了對HTML Form遞交前的JavaScript等狀態檢查，所以如果發現某個Form的onsubmit 綁定了 return false的動作，就自動終止當前的操作；相反，則繼續如常。
定位到問題，並經過粗略的原因分析之後，解決問題的辦法也就隨之而來。如果當前被執行的HTML Form被設置了 onsubmit 的檢查，則需要對已經設置的 onsubmit 進行重寫，使之能夠覆蓋之前的設置，尤其是之前 return false 的設置，以使得後續的Form遞交操作能夠順利進行。 改進主要集中在 _SUB 這個内部調用的子函數上。
在執行postForm.submit() 之前，對當前 postForm的onsubmit 進行檢查。
//postForm.submit(); // maybe fail due to this._DFM_F . 10:42 2020-07-04
if(postForm.onsubmit == null){
postForm.submit();
GTAj._DBG(GTAj.vA[‘ib’], ‘this._SUB’, ‘Sync form: [‘+postForm.name+’] is being submitted.’);
}
else{
GTAj.currentPostFormId = postForm.name!=” ? postForm.name : postForm.id;
postForm.onsubmit = (function(){
var myTimerId = window.setTimeout(function(formId){
document.getElementById(GTAj.currentPostFormId).submit();
GTAj._DBG(GTAj.vA[‘ib’], ‘this._SUB’, ‘Async form:[‘+GTAj.currentPostFormId+’] is being submitted.’);
}, 10); //- 0.01 sec
return true;
})();
}
如果當前被執行的 postForm的onsubmit 沒有被設置過，則繼續使用之前的邏輯，直接執行 postForm.submit();
如果當前被執行的 postForm的onsubmit已經被設置過，則需要重寫onsubmit的綁定與賦值操作。經過多次實驗，我采取了JavaScript anonymous function的方式，重新對當前postForm的onsubmit進行賦值操作。初始我們將一個匿名函數賦值給當前的 postForm, 形如:
postForm.onsubmit = function(){ return true; }
在我們的實測過程中，這一匿名函數，在不同應用場景和不同的瀏覽器中，仍有一定的隨機性出現匿名函數不被執行的情況。為保全起見，我們進一步地改進這個匿名函數，不但定義了匿名函數同時隨後執行這個你們函數，將返回值賦給 postForm.onsubmit .
在匿名函數體外，我們還通過全局變量 GTAj，將當前被執行的postForm的相關信息帶入匿名函數内；在匿名函數體内，我們設定了一個隨後立即執行的新的匿名函數，這第二個内嵌的匿名函數將完成這個表單的真實遞交動作。執行的時序變成： …. 1）定義一個匿名函數A—- 2）在匿名函數A内定義另一個異步的匿名函數B—- 3）執行這個匿名函數A —- 4）將匿名函數A的返回值true賦值給 postForm.onsubmit —- 5)時間觸發執行匿名函數B —– 6）實際執行postForm.submit() 操作 —– 7）監測服務器返回值進度….
改進后，分別在 Google Chrome，MS Edge 和 Mozilla Firefox 多個瀏覽器的不同應用場景下實測，均取得預期效果，不再發生或者隨機性發生，遞交Form未被執行的情況，故障問題得到順利解決。完整程序源代碼可以在 GTAjax 主頁( https://ufqi.com/dev/gtajax/ )和 GitHub上查詢（wadelau/GTAjax）。
這可能是軟件更新史上間隔最長的一次更新，GTAjax的官網主頁記錄記錄的上次更新時間為 2011-07， 距今已經九年過去了。著實令整個軟件作者也感到時光飛逝，一方面感慨時間過得太快，同時也對 GTAjax 歷時十多年，還能夠堅强、頑强地服務于業務系統的旺盛生命力感到一陣驚喜。
這不就是那種“Best as Air（好到無形）”極好的案例嗎？ 幾乎每個工作日打開的基於 gMIS 吉密斯系統，其中都有 GTAjax 工作的身影，而他總是能夠不負囑托，完成每一次基於 GTAjax 的HTTP請求。
實際上，2011年以來，GTAjax 也做過小幅的升級改進和Bug修復，根據軟件源代碼中的更新標記，至少有如下幾次。
* GTAjax.js
* @abstract: General-Targeted Ajax
* @author: wadelau@hotmail.com,wadelau@gmail.com
* @since: 2006-2-17 14:04
* @code: 5.7 // a.bc , funcs added b+, errs updated c+
* @NOTICE: DO NOT USE THIS COMMERICALLY WITHOUT AUTHOR’S PAPER AUTHORIZATION
* @update: Tue Feb 1 20:47:03 GMT 2011
* Wed Jan 26 17:31:33 GMT 2011
* Wed Jul 20 08:08:09 BST 2011
* Fri Mar 16 16:36:52 CST 2012
* 12:15 Friday, February 20, 2015
* Sun Jan 24 12:56:43 CST 2016
* Fri May 25 08:51:23 CST 2018, code format refine and cA.sort bugfix
* Wed Oct 31 21:57:26 CST 2018, +form Name validate
* 11:06 Friday, August 16, 2019, imprvs with form validate
* 11:55 2020-07-04, bugfix for submit fail with forceFrame.
GTAjax 初創于 2006年2月，距今已經有 15年的歷史了。對於日新月異的軟件及互聯網行業來説，這差不多是古董級的軟件了。然而，基於開放標準和成熟技術棧，15年后，GTAjax依然穩定運行和應用在各種Web軟件中，這不能不説是相當成功的案例。
可以設想和對比的是，在應用層軟件，有有多少能使用15年之久？不要說15年，基於私有類庫和標準而開發的軟件，可能5年、10年之後已經難以覓得蹤跡，GTAjax 伴隨 gMIS 吉密斯 等軟件能夠一直運行到現在，並繼續運行到下一個5年，10年，是一件值得慶賀的事情。
軟件的生命力或者生存周期有多久？需要多久? 摩爾定律說硬件計算速度每18個月翻倍，軟件是否也只能用18個月要改版、升級換掉，甚至是完全推導重建？
實際上，GTAjax 生存的越久，越有可能遇到“趕不上趟”的情況，畢竟技術的發展與進步，日新月異，每隔3-5年幾乎就是天翻地覆的改變。GTAjax能夠堅持其可用、好用、能用達15年之久，應該說算是某種“成功”。
幾乎同時期的很多軟件都已經銷聲匿跡了。也可以設想，如果不是使用的開放的HTML、CSS和JavaScript等標準，而是使用某一家公司的某項私有技術，其情況可能就完全無法預料，更誑論與時俱進、歷久彌新了。縱向地時間跨度看，要保護和珍視一個軟件，盡可能延遲其生命周期，保持旺盛生命力，唯一可取的方式就是使用開放的技術與標準，構建面嚮未來的軟件。
從這一方面來説，基於WEB的應用軟件已經完勝了基於某個公司或者平臺的“本地應用”。10年前，差不多是WEB軟件真大行其道的時候，以美國Apple公司的Appstore反其道而用之，强推基於其自有的平臺軟件（App），構築强大的軟件壁壘，同時引導、脅迫無數軟件開發者不斷的爲其開發軟件（App），短則數月，長則數十月，App的快速更迭，也意味著大量的新寫成的代碼，像曇花一現一般消失了。
當然，也有及其少數的本地應用App頑强地頻繁地更新升級穿越了10年以上的歲月時空，如游戲魔獸世界WoW，即時通信軟件騰訊QQ等。這其中也包括，Web軟件賴以運行的網絡瀏覽器，如MS IE，Mozilla Firefox，Google Chrome，Apple Safari，Opera等。
在人民網工作期間，儅其實我們用的基於WEB的内部辦公系統（OA）相當有些年份（5-6年？），當時覺得，爲何不升級采用新技術？ 甚至是再一個5-6年之後（10多年前），這個OA系統依然在運行中。現在想來，這是一筆極大的財富，因爲軟件的本身的技術棧是公開的標準，沒有很快地被業界全部抛棄，所以企事業單位的投資，得以延用至今繼續發揮作用。
當然，也不是說公開、開發的技術標準就止步不前，相反，公開、開放、開源的技術也在不斷的改進升級，只是由於影響巨大，各方需要多輪磋商，考慮各種因素，相對於一家公司的一項技術，其進度必然是緩慢的，當然也是理性而鑒定的。
比如 GTAjax 在開發計劃中，就規劃了 GTAjax-6.x 版本，主要考慮外部因素如下：
* 12:15 Friday, February 20, 2015
* 6.x Bears
HTML 5
ECMAScript 5, 6
HTTP/2 and Event-driven,
highly-cached,
code style of high-performance and readability
* in mind
尤其是其中的 HTML5，JavaScript 6 和 HTTP2 這些是在業界公開討論多年的技術標準，日益成熟，在新應用部署時會加快采用。相信在不久的將來，GTAjax-6.x 就緒時，能夠充分利用這些新技術特徵，在兼容之前的前提下，繼續為互聯網社區做出新的貢獻，下一個 15年，30年，50年。
與之相關 GTAjax更新Blog有：1）gMIS吉密斯更新Workflow工作流、FileMgr文件柜及GTAjax等模块（ https://ufqi.com/blog/gmis-workflow-filemgr-gtajax/ ），2）-gMIS, -GWA2, -GTAjax 一并更新 （ https://ufqi.com/blog/gmis-gwa2-gtajax-update/ ）。
世界仍不平靜，新冠肺炎疫情仍在傳播，愿軟件開發者多開發些生命周期更長的軟件，為世界和平貢獻智慧和力量，不要讓軟件成爲快消品, 而是要讓軟件成爲耐用品、藝術品。
-R/M2SR
https://ufqi.com/blog/gtajax-updt-form-submit-202007
