DOM事件標(biāo)準(zhǔn)定義了兩種事件流,這兩種事件流有著顯著的不同并且可能對(duì)你的應(yīng)用有著相當(dāng)大的影響。這兩種事件流分別是捕獲和冒泡。和許多Web技術(shù)一樣,在它們成為標(biāo)準(zhǔn)之前,Netscape和微軟各自不同地實(shí)現(xiàn)了它們。Netscape選擇實(shí)現(xiàn)了捕獲事件流,微軟則實(shí)現(xiàn)了冒泡事件流。幸運(yùn)的是,W3C決定組合使用這兩種方法,并且大多數(shù)新瀏覽器都遵循這兩種事件流方式。
默認(rèn)情況下,事件使用冒泡事件流,不使用捕獲事件流。然而,在Firefox和Safari里,你可以顯式的指定使用捕獲事件流,方法是在注冊(cè)事件時(shí)傳入useCapture參數(shù),將這個(gè)參數(shù)設(shè)為true。下面用個(gè)例子分別來(lái)測(cè)試這兩種事件流。
1、冒泡事件流
當(dāng)事件在某一DOM元素被觸發(fā)時(shí),例如用戶(hù)在客戶(hù)名字節(jié)點(diǎn)上點(diǎn)擊鼠標(biāo),事件將跟隨著該節(jié)點(diǎn)繼承自的各個(gè)父節(jié)點(diǎn)冒泡穿過(guò)整個(gè)的DOM節(jié)點(diǎn)層次,直到它遇到依附有該事件類(lèi)型處理器的節(jié)點(diǎn),此時(shí),該事件是onclick事件。在冒泡過(guò)程中的任何時(shí)候都可以終止事件的冒泡,在遵從W3C標(biāo)準(zhǔn)的瀏覽器里可以通過(guò)調(diào)用事件對(duì)象上的stopPropagation()方法,在Internet Explorer里可以通過(guò)設(shè)置事件對(duì)象的cancelBubble屬性為true。如果不停止事件的傳播,事件將一直通過(guò)DOM冒泡直至到達(dá)文檔根。
測(cè)試的HTML文件,其中用到了mootools-release-1.11.js,對(duì)mootools的代碼進(jìn)行了改動(dòng):
addListener: function(type, fn,setCapture){
if (this.addEventListener) this.addEventListener(type, fn, setCapture);
else {
this.attachEvent('on' + type, fn);
if (setCapture) this.setCapture(true);
}
return this;
}
給addListener方法里增加了setCapture參數(shù),用于測(cè)試捕獲事件流。
<body>
<div id="dd1-ct" style="width:400px;height:400px;border:1px solid #999;padding:2px">Container
<div id="dd1-item1" style="width:200px;height:200px;border:1px solid #999;padding:2px">Item1
<div id="dd1-item2" style="width:100px;height:100px;border:1px solid #999;padding:2px">Item2</div>
</div>
</div>
<div id='rh'></div>
</body>
效果:

js:
fn1=function(e){
// e.stopPropagation();
$('rh').innerHTML+='Item1 clicked!******';
};
fn2=function(e){
// e.stopPropagation();
$('rh').innerHTML+='Item2 clicked!-------';
};
fn=function(e){
// e.stopPropagation();
$('rh').innerHTML+='Container clicked!&&&&&&&&';
};
$('dd1-item2').addListener('click', fn2.bindWithEvent(),false);
$('dd1-item1').addListener('click', fn1.bindWithEvent(),false);
$('dd1-ct').addListener('click', fn.bindWithEvent(),false);
測(cè)試結(jié)果ie和ff下效果一致:?jiǎn)螕鬷tem2,會(huì)依次觸發(fā)fn2、fn1、fn;單擊item1,會(huì)依次觸發(fā)fn1、fn;單擊Container,只會(huì)觸發(fā)fn;當(dāng)在任何一個(gè)事件處理器里調(diào)用e.stopPropagation();都會(huì)阻止事件的冒泡。
2、捕獲事件流
事件的處理將從DOM層次的根開(kāi)始,而不是從觸發(fā)事件的目標(biāo)元素開(kāi)始,事件被從目標(biāo)元素的所有祖先元素依次往下傳遞。在這個(gè)過(guò)程中,事件會(huì)被從文檔根到事件目標(biāo)元素之間各個(gè)繼承派生的元素所捕獲,如果事件監(jiān)聽(tīng)器在被注冊(cè)時(shí)設(shè)置了useCapture屬性為true,那么它們可以被分派給這期間的任何元素以對(duì)事件做出處理;否則,事件會(huì)被接著傳遞給派生元素路徑上的下一元素,直至目標(biāo)元素。事件到達(dá)目標(biāo)元素后,它會(huì)接著通過(guò)DOM節(jié)點(diǎn)再進(jìn)行冒泡。
這里ie與ff存在著很大的差異,甚至ie6與ie7的表現(xiàn)也各不相同,所以分開(kāi)測(cè)試。
a、ff
事件從從DOM層次的根開(kāi)始往下傳遞時(shí),會(huì)被useCapture屬性為true的事件監(jiān)聽(tīng)器所捕獲,而到達(dá)目標(biāo)元素再?gòu)哪繕?biāo)元素冒泡時(shí),則會(huì)被useCapture屬性為false的事件監(jiān)聽(tīng)器所捕獲。當(dāng)在任何一個(gè)事件處理器里調(diào)用e.stopPropagation();都會(huì)阻止事件的傳播。
b、ie6
用事實(shí)說(shuō)話:
第一種情況:
$('dd1-item2').addListener('click', fn2.bindWithEvent(),true);
$('dd1-item1').addListener('click', fn1.bindWithEvent(),true);
$('dd1-ct').addListener('click', fn.bindWithEvent(),true);
單擊瀏覽器的任何位置,都只是觸發(fā)fn;
第二種情況:
$('dd1-item2').addListener('click', fn2.bindWithEvent(),true);
$('dd1-item1').addListener('click', fn1.bindWithEvent(),true);
$('dd1-ct').addListener('click', fn.bindWithEvent(),false);
單擊瀏覽器的任何位置,會(huì)依次觸發(fā)fn1、fn;
第三種情況:
$('dd1-item2').addListener('click', fn2.bindWithEvent(),true);
$('dd1-item1').addListener('click', fn1.bindWithEvent(),false);
$('dd1-ct').addListener('click', fn.bindWithEvent(),false);
單擊瀏覽器的任何位置,會(huì)依次觸發(fā)fn2、fn1、fn;
結(jié)論:如果HTML元素捕獲了通過(guò)該元素的setCapture()方法對(duì)這個(gè)元素的設(shè)置,依附于該元素的處理器將會(huì)被事件觸發(fā),即使setCapture()方法
被調(diào)用的這個(gè)元素不在目標(biāo)元素的祖先路徑中。事實(shí)上你甚至單擊瀏覽器的非頁(yè)面部分都會(huì)觸發(fā)事件處理器。并且事件一旦被捕獲就不會(huì)繼續(xù)再
往下傳播(即使該元素在目標(biāo)元素的祖先路徑中),而是立刻冒泡。e.stopPropagation();會(huì)阻止事件的冒泡。
c、ie7
測(cè)試效果與冒泡事件流一致。將對(duì)捕獲事件流的支持干掉了?
結(jié)論:正如mootools所做的,避免捕獲事件流。
posted @
2008-03-02 14:54 ronghao 閱讀(2004) |
評(píng)論 (0) |
編輯 收藏
工作流現(xiàn)在已經(jīng)應(yīng)用的非常廣泛了,審批OA等等自然不必多說(shuō),許多業(yè)務(wù)系統(tǒng)里也有大量的應(yīng)用。前兩天的
一個(gè)項(xiàng)目就是使用工作流將整個(gè)項(xiàng)目管理的過(guò)程進(jìn)行整合,包括了前期預(yù)算、項(xiàng)目進(jìn)度管理、合同管理等等。
可供選擇的工作流也很多,商業(yè)的、開(kāi)源的。那么你是如何評(píng)價(jià)一個(gè)工作流產(chǎn)品的好壞的呢?你的標(biāo)準(zhǔn)是什么?
當(dāng)然,用戶(hù)也經(jīng)常會(huì)問(wèn)我這個(gè)問(wèn)題,我的回答是:根據(jù)你實(shí)際的業(yè)務(wù)。是的,不管是什么樣的工作流,都是
為了滿足業(yè)務(wù)的需要,你把你的需求提出來(lái),我們看看是否滿足,不能直接滿足,最合適的間接方式又是什么。你說(shuō),我要有催辦。是的,我們有。你說(shuō),我要有任意回退和任意流。是的,我們有。你說(shuō),我想對(duì)流程實(shí)例進(jìn)行分級(jí)管理。oh,沒(méi)有也,重要嗎?讓我們想想其他辦法。你說(shuō),你們符合BPEL標(biāo)準(zhǔn)嗎?這個(gè)。。。你說(shuō),你們采用了petri網(wǎng)模型嗎?汗。。。你說(shuō),你們是SOA架構(gòu)嗎?。。。
我的衡量標(biāo)準(zhǔn)是這樣的:
1、流轉(zhuǎn)功能
包括了基本的工作流模式實(shí)現(xiàn),串行、并發(fā)、分支、匯聚、循環(huán)等等。這個(gè)是最基本的。其實(shí)打開(kāi)流程設(shè)計(jì)器拖拖拽拽很快就能知道這個(gè)產(chǎn)品到底實(shí)現(xiàn)了哪些流轉(zhuǎn)模型。實(shí)際這個(gè)的實(shí)現(xiàn)也是引擎的核心。有多種模型可以選擇。petri 模型應(yīng)該是最靈活的了,也有很大的實(shí)現(xiàn)難度。但是流程模型做這么靈活,到底實(shí)際能用上多少……就我個(gè)人的經(jīng)驗(yàn)來(lái)說(shuō),大部分的復(fù)雜性都是由流程的分支并發(fā)(m/n)引起的,最壞的辦法是強(qiáng)制要求客戶(hù)將這些并發(fā)的任務(wù)改成 step by step 的執(zhí)行。這樣犧牲一點(diǎn)效率,還是可以把項(xiàng)目做成的。
2、業(yè)務(wù)的內(nèi)在支持
比如說(shuō)催辦、時(shí)間服務(wù)、收回等等。我覺(jué)得這個(gè)與實(shí)際業(yè)務(wù)掛鉤,反而是最為主要的考慮。因?yàn)椴捎瞄g接的方式必然會(huì)產(chǎn)生編程,而很顯然會(huì)耗費(fèi)成本。
3、與業(yè)務(wù)的契合方式
流程維護(hù)流轉(zhuǎn)。業(yè)務(wù)還是自己實(shí)現(xiàn)。如何將這兩者很好的銜接起來(lái)。同時(shí)這個(gè)過(guò)程還存在權(quán)限的限定,每個(gè)運(yùn)行節(jié)點(diǎn)對(duì)業(yè)務(wù)的權(quán)限肯定存在差別,是否有一套完整的解決方案?當(dāng)然這其中也包括了組織機(jī)構(gòu)的適配,對(duì)各種組織模型的支持。
4、定義良好的API
通常會(huì)存在工作流無(wú)法直接滿足的業(yè)務(wù)場(chǎng)景,那么肯定需要程序直接調(diào)用工作流的API,清晰且簡(jiǎn)潔的API。
5、流程的仿真
這種仿真比較簡(jiǎn)單,目的在于檢驗(yàn)所定義的流程是否正確。出錯(cuò)要有明確的提示信息。普元的單點(diǎn)調(diào)試?
6、電子表單
我始終覺(jué)得電子表單目前實(shí)際應(yīng)用并不理想,它僅僅只能處理簡(jiǎn)單的業(yè)務(wù)。但是銷(xiāo)售的經(jīng)驗(yàn)告訴我,這是一個(gè)巨大的閃光點(diǎn)。用戶(hù)喜歡自己動(dòng)手。流程定義實(shí)際最終用戶(hù)很難實(shí)際操作。我在想:簡(jiǎn)化版本的流程設(shè)計(jì)器+電子表單也許會(huì)有很好的售前效果。
7、良好的售后
8、良好的最終用戶(hù)體驗(yàn)
9、性能
10、最好能夠和標(biāo)準(zhǔn)扯上關(guān)系,可是誰(shuí)知道我是否真的有關(guān)系呢?
posted @
2008-02-22 15:02 ronghao 閱讀(2899) |
評(píng)論 (5) |
編輯 收藏
這是一個(gè)完全基于js的應(yīng)用程序,區(qū)別于一般的web應(yīng)用,它是oaop。大概需要一些什么樣的工作呢?
大概的概念:
1、容器
是的,需要容器。容器的兩個(gè)目的:布局和管理組件。組件之間的相互通信以及影響都需要容器來(lái)協(xié)調(diào)。管理組件之間的狀態(tài),組件需要向容器進(jìn)行注冊(cè)。對(duì)組件傳播過(guò)來(lái)的事件,容器需要做出處理,調(diào)用相關(guān)其他組件的方法或者忽略或者繼續(xù)向上一級(jí)容器傳播。
2、組件
組件的目的是完全屏蔽對(duì)dom編程的依賴(lài),同時(shí)屏蔽底層的瀏覽器事件,例如鼠標(biāo)單擊、雙擊等等,對(duì)這些事件進(jìn)行完全的封裝。組件有著自己的生命周期:初始化、渲染、重畫(huà)、銷(xiāo)毀等等。由組件完成頁(yè)面的渲染工作,例如節(jié)點(diǎn)、畫(huà)板、連線等等。
3、模型
在頁(yè)面進(jìn)行建模是必要的,例如活動(dòng)節(jié)點(diǎn)、流程等等,這些模型與組件銜接,它們之間的狀態(tài)互相影響,比如節(jié)點(diǎn)組件名稱(chēng)的改變實(shí)際影響的是所對(duì)于節(jié)點(diǎn)模型的屬性。畫(huà)板節(jié)點(diǎn)的增加實(shí)際也會(huì)給響應(yīng)的流程定義模型新增一個(gè)活動(dòng)節(jié)點(diǎn)。
4、與服務(wù)器交互
與服務(wù)器的交互完全基于xml。流程定義模型有著自己的xml方法,由xml解析為模型,由模型解析為xml,雙向的過(guò)程。本地存儲(chǔ)。很自然的選擇。
可能的難點(diǎn):
最大的難點(diǎn)就是組件的實(shí)現(xiàn),事件的處理以及傳播機(jī)制。
開(kāi)發(fā)的過(guò)程:
1、底層庫(kù)的選擇
面向?qū)ο蟮拈_(kāi)發(fā)方式,底層庫(kù)需要完成的工作:繼承、接口實(shí)現(xiàn)、事件的統(tǒng)一處理接口、element DOM編程的封裝。
2、基本組件的開(kāi)發(fā)
畫(huà)板、圖形組件、連線組件、彈出面板、簡(jiǎn)單表格組件、樹(shù)等等。封裝基本的事件。可以定制事件。
3、容器的開(kāi)發(fā),管理組件
組件實(shí)際也是容器的實(shí)現(xiàn),比如畫(huà)板的概念。畫(huà)板中節(jié)點(diǎn)之間的互相影響。
4、加入模型的支持
5、xml與模型之間的js解析
參考:
ext是一個(gè)不錯(cuò)的參考,但是太笨重,功能越多越緩慢,輕量實(shí)現(xiàn)。主要參考其中容器以及組件的概念。
draw2d 實(shí)現(xiàn)太簡(jiǎn)單,基本就是一個(gè)圖形庫(kù),考慮其中對(duì)圖形組件的實(shí)現(xiàn)。
posted @
2008-02-13 22:08 ronghao 閱讀(2986) |
評(píng)論 (4) |
編輯 收藏
內(nèi)容
序
致謝
關(guān)于作者
第1章 AJAX和富互聯(lián)網(wǎng)應(yīng)用
轉(zhuǎn)變中的Web
傳統(tǒng)Web應(yīng)用的痛處
AJAX止痛藥
企業(yè)中的AJAX
采用AJAX的驅(qū)動(dòng)因素
可用性
網(wǎng)絡(luò)利用率
以數(shù)據(jù)為中心
遞增的技巧、工具和技術(shù)升級(jí)
服務(wù)器不可知論
關(guān)于應(yīng)用
AJAX技術(shù)
編程模式
AJAX的替換技術(shù)
XUL
XAML
Java Applets 和Web Start
Adobe Flash,F(xiàn)lex和Apollo
OpenLaszlo
小結(jié)
資源
第2章 AJAX組成技術(shù)(AJAX Building block)
JavaScript
JavaScript類(lèi)型
閉包
面向?qū)ο蟮腏avaScript
Prototype屬性
面向?qū)ο缶幊?OOP)和繼承(Inheritance)
易變性(Mutability)
線程(Threading)
錯(cuò)誤處理(Error Handling)
命名空間(Namespacing)
文檔對(duì)象模型(Document Object Model)
基本原理
操作DOM
層疊樣式表
繼承和層疊(Inheritance and the Cascade)
內(nèi)聯(lián)樣式
樣式表
動(dòng)態(tài)樣式
事件
事件流
事件綁定
跨瀏覽器事件
事件對(duì)象
客戶(hù)端通信(Client-Side Messageing)
XMLHttpRequest基礎(chǔ)
處理數(shù)據(jù)
小結(jié)
資源
第3章 Web瀏覽器中的AJAX
增量的AJAX
對(duì)服務(wù)器影響
HTML標(biāo)準(zhǔn)
文檔類(lèi)型定義(Document Type Definitions)
盒子模型
啟動(dòng)加載AJAX組件
onload事件
瀏覽器
編碼技巧
模型-視圖-控制器
視圖
控制器
模型
AJAX MVC
AJAX模型
AJAX視圖
AJAX控制器
面向方面的JavaScript
小結(jié)
資源
第4章 AJAX組件
命令式組件
聲明式組件
服務(wù)器端聲明式編程
聲明式Google地圖
替代方法
自定義聲明式組件
行為式組件
聲明式組件
關(guān)于聲明
構(gòu)建組件
基本功能
連接到服務(wù)器
最終版本
小結(jié)
資源
第5章 從設(shè)計(jì)到部署
設(shè)計(jì)
為AJAX建模
應(yīng)用模型-視圖-控制器模式
優(yōu)先考慮性能問(wèn)題
設(shè)計(jì)原型
線框繪制
驗(yàn)證設(shè)計(jì)決議
測(cè)試
測(cè)試驅(qū)動(dòng)開(kāi)發(fā)
調(diào)試
部署
JavaScript壓縮
圖片
合并
保護(hù)知識(shí)產(chǎn)權(quán)
文檔
小結(jié)
資源
第6章 AJAX架構(gòu)
多層架構(gòu):從單層到多層
異步消息
輪詢(xún)
服務(wù)器推送
Comet
跟蹤請(qǐng)求
緩存:處理數(shù)據(jù)
基本緩存
在組件中緩存
在瀏覽器中緩存
在服務(wù)器中緩存
在數(shù)據(jù)庫(kù)中緩存
MySQL
MS SQL Server
Oracle
更新服務(wù)器端模型:并發(fā)
悲觀鎖定
只讀鎖定
樂(lè)觀鎖定
沖突鑒定
沖突解決
自動(dòng)化的沖突解決
流量控制(Throttling)
客戶(hù)端
服務(wù)端
可伸縮性
負(fù)載平衡和群集
AJAX可伸縮性問(wèn)題
離線AJAX
Firefox離線存儲(chǔ)
Internet Explorer userData離線存儲(chǔ)
使用Flash客戶(hù)端存儲(chǔ)
離線AJAX和并發(fā)
小結(jié)
資源
第7章 Web服務(wù)和安全性
Web服務(wù)
Web服務(wù)協(xié)議
表象狀態(tài)傳輸
XML遠(yuǎn)程過(guò)程調(diào)用
Web服務(wù)
選擇合適的工具
客戶(hù)端的SOAP
IBM Web服務(wù)JavaScript庫(kù)
Firefox
Internet Explorer
跨域Web服務(wù)
服務(wù)器代理
URL片段標(biāo)識(shí)符
Flash跨域XML
腳本注入
安全性
AJAX的安全性考慮
跨域漏洞
跨站腳本
跨站偽造請(qǐng)求
JavaScipt劫持
SQL注入
預(yù)處理語(yǔ)句
存儲(chǔ)過(guò)程
XPath注入
數(shù)據(jù)加密和隱私
防火墻
小結(jié)
資源
第8章 AJAX可用性
常見(jiàn)問(wèn)題
后退按鈕和書(shū)簽
頁(yè)面大小
自動(dòng)提交
可訪問(wèn)性
識(shí)別用戶(hù)的可訪問(wèn)性需求
JavaScript和Web可訪問(wèn)性
屏幕閱讀器和可訪問(wèn)性
兼容JAWS的AJAX交互
鍵盤(pán)可訪問(wèn)性
可用性測(cè)試
迅速而又隨性的測(cè)試
招募參與者
設(shè)計(jì)和運(yùn)行測(cè)試
軟件斷言測(cè)試
用于測(cè)試可用性的工具
對(duì)軟件輔助測(cè)試的一般忠告
小結(jié)
資源
第9章 用戶(hù)界面模式
顯示模式
動(dòng)畫(huà)模式
交互模式
基本交互模式
小結(jié)
資源
拖拽資源
進(jìn)度欄資源
活動(dòng)指示器資源
顏色淡出資源
即時(shí)編輯資源
向下鉆取資源
即時(shí)搜索資源
即時(shí)表單資源
第10章 風(fēng)險(xiǎn)和最佳實(shí)踐
風(fēng)險(xiǎn)來(lái)源
技術(shù)風(fēng)險(xiǎn)
文化和政治風(fēng)險(xiǎn)
市場(chǎng)風(fēng)險(xiǎn)
技術(shù)風(fēng)險(xiǎn)
范圍
瀏覽器能力
可維護(hù)性
向前兼容
第三工具支持和代碼過(guò)時(shí)
文化和政治風(fēng)險(xiǎn)
終端用戶(hù)的期待
可培訓(xùn)性
合法性
市場(chǎng)風(fēng)險(xiǎn)
搜索引擎的可訪問(wèn)性
范圍
貨幣化
風(fēng)險(xiǎn)評(píng)估和最佳實(shí)踐
采用特定的AJAX框架或者組件
漸進(jìn)增強(qiáng)和不唐突的JavaScript
Google 網(wǎng)站地圖
可視化的提示
避免鍍金式設(shè)計(jì)
采用一種收益模型
把培訓(xùn)作為應(yīng)用的一部分
小結(jié)
資源
搜索引擎優(yōu)化
統(tǒng)計(jì)
網(wǎng)站地圖
屏幕截取工具
第11章 案例研究
基于Web2.0 重新武裝美國(guó)國(guó)防部
背景
挑戰(zhàn)
解決方案
采用技術(shù)
成果
Agrium公司整合AJAX技術(shù)到業(yè)務(wù)
背景
挑戰(zhàn)
解決方案
采用技術(shù)
成果
AJAX助力國(guó)際運(yùn)輸和物流公司
背景
挑戰(zhàn)
解決方案
采用技術(shù)
成果
小結(jié)
資源
附錄A OpenAjax Hub
主要特性:發(fā)布/注冊(cè)管理器
范例
未來(lái)對(duì)OpernAjax Hub支持的工具包
索引
posted @
2008-01-24 18:21 ronghao 閱讀(658) |
評(píng)論 (0) |
編輯 收藏
時(shí)間真快,一晃08年都過(guò)了半個(gè)月。一直很忙,也不知道在忙些什么東西。領(lǐng)導(dǎo)催著要份年終總結(jié),于是就有了這個(gè)東西。還是分成兩個(gè)部分:工作和生活。
工作:
1、年初的時(shí)候繼續(xù)業(yè)務(wù)平臺(tái)的開(kāi)發(fā),主要是修改BUG和書(shū)寫(xiě)使用文檔,公司開(kāi)始增加測(cè)試的崗位,平臺(tái)也開(kāi)始有訂單,于是BUG像雨后春筍般的茁壯成長(zhǎng)出來(lái)。實(shí)際一直到現(xiàn)在,那份長(zhǎng)長(zhǎng)的BUG單依舊存在,改不完的BUG。現(xiàn)在有很深的體會(huì):一個(gè)好的產(chǎn)品,并不在于采用了多么先進(jìn)的技術(shù),重要的是要成熟,要貼近業(yè)務(wù),而這需要的是時(shí)間和大量的項(xiàng)目經(jīng)驗(yàn)。所以,要是想節(jié)約成本采購(gòu)一個(gè)業(yè)務(wù)平臺(tái),首先需要考慮的是這個(gè)平臺(tái)存在幾年了?都被哪些實(shí)際項(xiàng)目采用過(guò)?它面對(duì)的業(yè)務(wù)是什么,是否符合我項(xiàng)目大部分的需求?對(duì)于號(hào)稱(chēng)采用很多新技術(shù)和通用性非常強(qiáng)且剛開(kāi)發(fā)出來(lái)的所謂平臺(tái)一定要慎用,很可能你就成了實(shí)驗(yàn)品。
2、業(yè)務(wù)平臺(tái)的價(jià)值。其實(shí)業(yè)務(wù)平臺(tái)是有很大的存在價(jià)值的。這個(gè)價(jià)值就是業(yè)務(wù)。我們公司產(chǎn)品的口號(hào)是:釋放你的技術(shù),專(zhuān)注你的業(yè)務(wù)。我認(rèn)為這個(gè)口號(hào)相當(dāng)不妥,正確的應(yīng)該是:發(fā)揮你的技術(shù),我們替你思考業(yè)務(wù)。業(yè)務(wù)平臺(tái)還有生存的意義,至于意義單一的所謂開(kāi)發(fā)平臺(tái),我看還是洗洗睡吧。
3、5月份開(kāi)始進(jìn)入工作流的開(kāi)發(fā),一直到現(xiàn)在。對(duì)工作流有了很多新的認(rèn)識(shí)。工作流應(yīng)該算是公司最核心的產(chǎn)品了。代碼很臃腫,沒(méi)有測(cè)試,但是分層還是非常的清晰。期間開(kāi)始增加測(cè)試并增加功能,對(duì)引擎部分做了部分的重構(gòu)。中間也陸續(xù)做過(guò)工作流的售前和售后工作。工作流,感覺(jué)是越來(lái)越普及了。但是感覺(jué)市場(chǎng)卻沒(méi)有想象的那么好,單獨(dú)的工作流引擎有沒(méi)有前景?其實(shí)可以這樣分析:很多行業(yè)都有他們自己針對(duì)的行業(yè)軟件公司,這些公司都有自己的業(yè)務(wù)平臺(tái)和流程組件,雖然不是獨(dú)立對(duì)外賣(mài)的;另外就是中小型企業(yè)和客戶(hù)采用開(kāi)源的工作流引擎了,這樣積累的使用經(jīng)驗(yàn)可以成為公司的財(cái)富,只要把核心人員留住,就不用每個(gè)項(xiàng)目都去購(gòu)買(mǎi)一個(gè)商業(yè)工作流了,節(jié)約成本;可不可以這么認(rèn)為:商業(yè)工作流的市場(chǎng)本來(lái)就很小呢?
4、12月到新疆出了趟差,然后就是全力開(kāi)發(fā)新疆的項(xiàng)目了。這是一個(gè)大集中的項(xiàng)目,也就是一套系統(tǒng),所有分公司一起使用,最 緊迫的問(wèn)題就是組織結(jié)構(gòu)、權(quán)限以及數(shù)據(jù)(包括流程)的分級(jí)管理了。現(xiàn)在是業(yè)務(wù)需求基本都滿足,但是可以想象未來(lái)性能的壓力,工作還會(huì)有很多。
個(gè)人技術(shù):
1、上半年看過(guò)一些敏捷和UML的書(shū)籍。敏捷感覺(jué)已經(jīng)是一個(gè)被用濫的詞語(yǔ),人人頭上都頂著一個(gè)敏捷的帽子,就像言必稱(chēng) spring"hibernate一樣,有些惡心了。看過(guò)這些書(shū),其實(shí)體會(huì)最深的還是如何開(kāi)發(fā)出一個(gè)大家都能讀懂的代碼,如何與他人交流,能讓別人看懂的代碼就是好代碼。至于UML,好像也能畫(huà)上和看懂幾個(gè)了。
2、最后一個(gè)季度和朋友一起翻譯了《Enterprise AJAX》這本書(shū),重新對(duì)ajax有了興趣,翻譯確實(shí)是一件辛苦的事情,但是現(xiàn)在回憶起來(lái)卻很是覺(jué)得有意義。最直接的就是翻譯水平有了很大長(zhǎng)進(jìn),然后就是ajax有了一些新的認(rèn)識(shí)。現(xiàn)在看Ext的代碼,想著能否有擴(kuò)展為類(lèi)swing框架的可能性。期間參與了滿江紅組織的seam翻譯工作,自己做的工作很少,純屬充數(shù),算是了解了一把seam。
3、我和老婆說(shuō),怎么今年就感覺(jué)進(jìn)步?jīng)]有去年那么明顯呢?老婆說(shuō),因?yàn)槟闳ツ昶瘘c(diǎn)太低!于是釋然。
生活:
1、年初買(mǎi)了房子了,注明一下:是在老婆強(qiáng)烈要求下買(mǎi)的。地點(diǎn)在燕郊。
2、關(guān)注了廈門(mén)PX、上海磁懸浮,除去工作,開(kāi)始關(guān)注很多東西,也開(kāi)始看歷史。
08的展望:
1、結(jié)婚
2、開(kāi)發(fā)一個(gè)基于js的工作流設(shè)計(jì)器,能否完成?
3、做了3年的開(kāi)發(fā)工作了,工作上能否有新的挑戰(zhàn)?
4、多看點(diǎn)非技術(shù)書(shū),多出去轉(zhuǎn)轉(zhuǎn),善待自己和親人。
posted @
2008-01-18 16:47 ronghao 閱讀(788) |
評(píng)論 (0) |
編輯 收藏