把firefox下js程序向ie兼容，一直用firefox調試，今天在ie下跑跑遇到了很多問題。
1.程序中用到prototype.js，對于事件監(jiān)聽，我一直這樣處理
在firefox下完全正常，但在ie下就找不到視圖所附加的對象了，改回來
這樣兩個瀏覽器都可以跑。附一個簡單的測試
2.處理td的跨行和跨列，都必須這樣寫
注意rowSpan，colSpan中間字母都是大寫的，而寫成rowspan,colspan在firefox下是沒有任何問題的。
3.在拖拽層的時候會出現鼠標經過的文字被選中的現象，解決這個問題非常簡單，當你開始拖拽前即你用鼠標點中你想要拖拽的層，這時候對事件進行處理

e=e||window.event;
if(e.stopProgation){
e.stopPropagation();
}
else{
e.cancelBubble?=?true;
}
if(e.preventDefault){
e.preventDefault();
}
else{
e.returnValue?=?false;
}?

如果使用prototype.js，可以簡單為一行代碼

昨天發(fā)了個很什么的隨筆，今天把與集群有關的東西搜了搜。整理一下。
什么是集群，集群的概念。下面這個BLOG講的非常清楚：
http://blog.csdn.net/ESoftWind/archive/2006/10/19/1341089.aspx
web層次的集群方案討論，看完javaeye相關的討論，你會大概了解：
http://www.javaeye.com/topic/20298
注意里面robbin的無共享架構（Share Nothing Architecture）SNA。
web層次的集群主要技術就是：負載均衡和http session的失敗轉移。
負載均衡不再多說，焦點在于http session的失敗轉移。各個節(jié)點的http session復制會極大的影響性能。如何避免，robbin提出保持每個節(jié)點的無狀態(tài)性，不再使用Session來保持全局狀態(tài)。用戶標示從cookie取得，假設不使用分布式Cache，session直接放在數據庫中。他推薦了memcached作為分布式Cache，這樣在從數據庫讀取session時中間又隔了一層Cache來提高性能。
大致的方法是這樣：用戶登陸的時候給他一個cookie，存放userId，同時給這個用戶分配一個Session，存放user對象，然后 把這個session保存到數據庫和分布式 Cache里。黏性會話。寫一個filter或者 webwork攔截器對用戶請求進行攔截，如果他有cookie，但是session里面沒有user對象，說明前一個節(jié)點down掉了，就根據 cookie里面的userId查數據庫或者是分布式 Cache獲得先前保存的session，把原先的session復制到他的新session里面。這樣各個節(jié)點間的 session就不用復制，因為 session是沒有狀態(tài)的。我們的程序對使用session不受影響，只是session里的對象要可序列化，當改變session里的對象時需要同步 到cache和數據庫。當然，效率的原因，session里面東西越少越好，越穩(wěn)定越好。
誰有這方面的經驗？
最近要開發(fā)一個與拍賣有關的大訪問量交易網站。一直做電子政務，對這方面沒有任何經驗。一開始考慮用php,mysql開發(fā)，后來由于覺得和交易相關，數據的一致性和安全一定很重要，最后考慮用java開發(fā)。
我不清楚在做這個開發(fā)時和平時相比有哪些需要注意的地方，我想到的有：
1.webwork+spring+hibernate這種組合方式是否可行。據說tobao用了ejb，雖說個人并未覺得ejb哪點好，但別人 既然用了就肯定有它的一定道理；
2.數據的緩存肯定是必須的，但哪些是最需要被緩存的數據？
3.dba肯定需要，在沒有dba的情況下，涉及數據庫時應該注意什么；
4.這樣的一個系統，它的性能肯定非常主要。它最有可能的瓶頸會發(fā)生在什么地方？
5.我們的理想工期會有多長，3到5個開發(fā)人員。
6.jms遠程異步調用的支持。
目前想到的大概這些，希望有經驗的朋友給些建議。我對這個項目目前還沒有很大的把握。 這個禮拜一直在寫日歷。把以前的JS全部推翻了，重新再寫。開發(fā)工具使用了aptana，調試用firefox的javascript debugger.aptana開始使用的時候還是挺爽，隨著代碼量的增長，然后經常是代碼高亮顯示不了了，更不要說提示了。這點IDEA6.0顯然要更加完善，直接可以方便的查找調用的函數。但是IDEA太笨重，不清爽。aptana寫CSS還是相當方便的。
開始使用stripes，一切看起來都不錯。
在家里安裝了subvision ，可是怎么也跑不起來，難道人品有問題？去年在公司配過一次，一點問題都沒有的。
火車票還沒著落，著急！
明天公司開年會，要集體K歌，嗓子不好，準備合唱。 獲得列表
在上一步中我們已經把數據保存到了內容倉庫中，那我們如何確定數據確實保存進去了呢？getBlogList() 這個方法將返回根節(jié)點下所有名為blogEntry.的子節(jié)點。

一旦你獲得了根節(jié)點這個對象，你就可以通過調用getNodes()這個方法來獲取它所有的子節(jié)點。如果這個節(jié)點沒有子節(jié)點，將返回一個空的NodeIterator 對象。我們可以遍歷這個NodeIterator 對象來獲得名為blogEntry 的節(jié)點集合，然后通過getProperty()方法來獲得節(jié)點上的屬性，即我們保存的真實數據。getProperty()方法返回Value對象的一個實例。因為存儲數據類型的不同，所以返回的Value對象實例是不同的。根據不同的數據類型，你應該調用特定的方法來獲取數據，比如getString()來獲取字符串，而getDate()獲得一個日期。

查找內容（用XPath的方式）
JSR-170定義了兩種方式來查找內容（也可以理解為查找節(jié)點）。一種使用XPath語法，另一種使用SQL語法。JSR-170要求Level 1必須實現XPath的方式，而SQL的方式則作為一個可選的功能。

XPath原本是一種設計用來查找XML元素的語言。因為我們的workspace是樹狀的結構，很像XML。所以XPath語法非常適合于在這里查找內容。下面的代碼演示了通過作者名來查找節(jié)點。

首先獲得session 對象，通過它獲得它連接的workspace，然后就可以通過workspace獲得這個workspace的QueryManager 。QueryManager 接口定義了很多用來查詢的方法。接下來我們要做的是創(chuàng)建一條查詢語句。我們這里這樣寫"http://blogEntry[@blogAuthor='<bloggerName>'"。這句話的意思是查找所有名為blogEntry ，含有blogAuthor 屬性且屬性值為<bloggerName>的節(jié)點。具體可以看JSR-170規(guī)范。

通過queryManager's createQuery()方法創(chuàng)建一個查詢對象，這個方法需要兩個參數，一個是我們的查詢語句，另一個是查詢的方式，這里使用XPath。獲得這個Query 查詢對象后，調用它的execute() 方法開始執(zhí)行查詢，返回一個QueryResult 對象。注意，查詢的結果受到當前session的限制，換句話說，就是如果這個session沒有權限查看一個特定的節(jié)點，哪怕這個節(jié)點滿足我們查詢的條件，在我們的查詢結果里也是看不到這個節(jié)點的。所有的查詢數據來自于該workspace已經持久化的數據，哪些已經改變但還沒有通過session.save()(item.save())持久化到workspace的數據不在查詢之列。獲得QueryResult 對象后，我們就可以通過調用getNodes()方法來獲得符合查詢條件的節(jié)點的一個遍歷。

剩下的兩個未實現的方法是updateBlogEntry() 和 removeBlogEntry()，它們實現起來都很簡單。我們把BOLG 標題作為主鍵，通過標題來獲得相關的節(jié)點。在updateBlogEntry()方法里，我們直接設定需要改變的屬性；在 removeBlogEntry()方法里，我們獲得目標節(jié)點后直接在節(jié)點上調用remove()方法。最后別忘了一定要調用session.save()方法把我們改變的數據持久化。

處理二進制內容
對內容倉庫來說，處理二進制內容是個很基本的要求，比如說圖片?，F在我們的示例程序容許給每個BLOG附加一張圖片。下面分別是附加圖片和獲取圖片的方法。

正如你看到的那樣，我們的代碼在處理二進制內容和一般內容間并沒有什么太大的區(qū)別。僅僅一點不同的是你要通過InputStream 對象來保存和獲取二進制數據。在我們的配置文件里關于persistent manager會有一個externalBLOBs 屬性。把這個屬性設為true, 圖片將會保存在文件里，相反則會保存在數據庫的blob字段里。

總結
到這里，我們對 JSR-170, Jackrabbit以及如何使用 JSR-170 API開發(fā)一個簡單的應用程序都有了大概的了解。我們的討論更多的在于基礎。相信大家一定會對內容倉庫有個初步的認識。