posts - 262,  comments - 221,  trackbacks - 0
          12 2009 檔案
          【原】RSS工具開發手記(12)---Informa的parsers包      摘要: 可以看到,對于這個解析過程,一般的步驟就是:
          A.獲取channnel下的某個子節點元素
          B.如果該子節點元素有子元素或屬性,則繼續遞歸訪問
          C.調用該channnel子元素的createXxx方法加載或創建該子元素
          D.調用Channel的setXxx方法添加該子元素到channel實例中  閱讀全文
          posted @ 2009-12-30 10:45 Paul Lin 閱讀(251) | 評論 (0)  編輯
          【原】RSS工具開發手記(11)---Informa的parse包      摘要: FeedParser是一個facade類,這個類的工作就是根據讀入的RSS Feed的協議系和版本“委托(delegate)”給已經硬編碼的規則(concrete rules)指定的解析器,而且這些解析器是私有的。這意味著:用戶不能直接調用一個RSS_0_91_Parser類的實例來進行解析工作。  閱讀全文
          posted @ 2009-12-29 15:56 Paul Lin 閱讀(1485) | 評論 (0)  編輯
          【原】RSS工具開發手記(10)---Informa的impl.hibernate包      摘要: ChannelBuilder對channel object的創建原則就是:
          A.如果能夠從持久層中找到對應的記錄,那么從持久層返回
          B.如果找不到,則創建它并持久化它,然后返回該對象(已持久化)

          只要記得的一點就是:從ChannelBuilder返回的對象都是已經持久化的。  閱讀全文
          posted @ 2009-12-28 15:57 Paul Lin 閱讀(1240) | 評論 (0)  編輯
          【原】RSS工具開發手記(09)---Informa的impl.hibernate包      摘要: 經過和impl.basic包中Channel的比較,發現兩者的實現有如下的不同:

          A.構造方法中多了3個方法,其中兩個是使用title和location來構造的,最后一個是使用Element,title,location來構造的
          B.從Hibernate中檢索出來的是不用設置ID的,而從內存中生成的必須使用IdGenerator產生唯一ID
          C.basic實現中沒有getLocationString方法和setLocationString方法
          D.basic實現中沒有getSiteString方法和setSiteString方法
          E.basic實現中沒有getGroup方法和setGroup方法
          F.basic實現中沒有getFormatString和setFormatString方法
          G.basic中沒有setItems方法,而且getItems方法中的實現不同(basic采用了同步的hashset,而hibernate沒有)
          H.basic中的addItem方法是添加到hashmap,而hib  閱讀全文
          posted @ 2009-12-28 10:51 Paul Lin 閱讀(232) | 評論 (0)  編輯
          【原】RSS工具開發手記(08)---Informa的build.xml      摘要: 其中dbscheme是關鍵,它的主要工作包括:
          A.創建用于保存DDL輸出結果的scripts目錄
          B.定義一個名為schemaexport的Ant task,用于把hbm文件導出為ddl文件
          C.執行schemaexport任務,把classes目錄下的hbm文件export成DDL,并輸出到指定的位置
          D.輸出執行結果信息  閱讀全文
          posted @ 2009-12-23 10:45 Paul Lin 閱讀(1343) | 評論 (0)  編輯
          【原】RSS工具開發手記(07)---Informa的impl.basic包      摘要: 這個ID生成類采用了系統當前時間作為隨即數產生的種子,這個并不難理解。但是有一個地方需要我們注意的就是關鍵字transient的使用。這個關鍵的作用是告訴編譯器假設該類的對象被序列化了,這個值不需要被保存。因為它是“瞬時”的。  閱讀全文
          posted @ 2009-12-23 00:03 Paul Lin 閱讀(1337) | 評論 (0)  編輯
          【原】RSS工具開發手記(06)---Informa的impl.basic包      摘要: 在ChannelBuilder下有幾種類型的方法:
          ★構造方法和初始化方法:即創建Channel對象的方法及初始化的方法
          ★元素構建方法:即構建Channel子元素的方法
          ★事務控制方法:即控制構建,析構過程的方法  閱讀全文
          posted @ 2009-12-22 23:52 Paul Lin 閱讀(1270) | 評論 (0)  編輯
          【原】RSS工具開發手記(05)---Informa的impl.basic包      摘要: 總結起來,channel的創建,更新過程如下:
          ①接收經過ChannelParser解析后的XML Element元素,和其他一系列屬性,調用構造方法
          ②構造方法為channel生成一個全局唯一ID
          ③構造方法創建item列表,觀察者列表,設置好分類(Category),首次更新時間
          ④如果有新item到來,則添加到item列表,同時更新item的channel歸屬
          ⑤如果現有channel更新,則設置最新更新時間
          ⑥通知每一個已注冊的觀察者有事件發生  閱讀全文
          posted @ 2009-12-22 23:31 Paul Lin 閱讀(1256) | 評論 (0)  編輯
          【原】RSS工具開發手記(04)---Informa的core包      摘要: Informa的core包介紹如下:

          “This package contains interfaces for the news channel objects, it builds the core API for all news channel storage implementation. ”

          從上面這句話來看,core包里面定義的都是關于“news channel objects”的接口---實際上就是RSS協議中的channel和item元素。經過一個多小時查看源代碼和閱讀API,發現Informa對core包的設計有如下特點:

          core包中的元素被分為標記接口、實體接口、行為接口  閱讀全文
          posted @ 2009-12-21 22:09 Paul Lin 閱讀(1246) | 評論 (0)  編輯
          【原】RSS工具開發手記(03)---初始Informa      摘要: Informa的API結構如下:

          ★core包:
          核心包。訂閱了RSS中channel,item等一系列元素和元數據的接口

          ★impl.basic包:
          基本功能包。使用in-memory模式實現了core包訂閱的接口

          ★impl.hibernate包:
          基于hibernate實現的包,使用關系型數據庫模式實現了core包定義的接口

          ★parsers包:
          定義了永遠解析channel,item的解析器工具

          ★exporters包:
          定義了一組把channel,item導出成各種協議格式的工具

          ★search包:
          定義了用于全文搜索channel,item的工具

          ★utils.manager.memory包:
          定義了一組用于管理“in-memory”模式持久化的工具

          ★utils.manager.hibernate包:   閱讀全文
          posted @ 2009-12-21 15:39 Paul Lin 閱讀(1258) | 評論 (0)  編輯
          【原】RSS工具開發手記(02)---工欲善其事,必先利其器      摘要: 選擇一個開源框架,我的標準有幾條:

          ★良好的文檔和源代碼管理:這是最基本的一條,想RSSLibJ這種連文檔、官網都沒有的一律pass掉
          ★持續的改進:這是第二個重要的,像上面某些工具從02年后就不再更新了,出了問題你找誰訴苦去
          ★簡單和易上手:在短時間內可以迅速依樣畫葫蘆
          ★活躍的社區:參與的人越多軟件成長得越多。我不是特別在乎軟件目前的使用率,因為好的軟件都是慢慢出名的  閱讀全文
          posted @ 2009-12-21 11:52 Paul Lin 閱讀(1361) | 評論 (0)  編輯
          【原】RSS工具開發手記(01)---Kick off      摘要: ◆軟件必須適應不同的終端,不同的訪問方式,不同版本的協議。對設計通用性要求較高
          ◆軟件必須解析和生成XML,涉及到大量的字符串和格式處理。對XML和性能要求較高
          ◆軟件必須具備實時監控功能,且具備主動推送功能,對多線程和異步通訊要求較高
          ◆軟件必須支持不同的持久化方式,對緩存和持久化要求較高
          ◆軟件必須支持基于全文的搜索,對搜索技術有一定要求
          ◆軟件界面必須是支持拖拽功能的,對GUI和Ajax有一定要求  閱讀全文
          posted @ 2009-12-18 12:14 Paul Lin 閱讀(309) | 評論 (0)  編輯
          【原】SVN In Action系列發布      摘要: SVN是一個開放的、免費的版本控制管理工具,相比CVS,Perforce等其他工具,SVN在版本模型,鎖定策略方面要更加靈活高效。下面就讓我們開始一步一步地學習如何使用SVN,如何把版本控制融入到日常工作中,更重要的是在學習版本控制的過程中樹立起團隊合作的理念。

          關于SVN的參考資料,最好的莫過于其官方文檔《Version Control with Subversion》,作為新手一定要看的是里面的第一章《Fundamental Concepts》和第二章《Basic Usage》以及第九章《Subversion Complete Reference》。

          為了做到真正的In Action,我采用了Step-by-Step的方式,模擬一個項目從檢出項目開始,到修改本地副本,再到提交變更,解決沖突等一系列的實際工作中會遇到的場景,期望通過這些場景和任務來對SVN和版本控制、團隊合作有一個基本的認識  閱讀全文
          posted @ 2009-12-13 12:29 Paul Lin 閱讀(3469) | 評論 (5)  編輯
          【原】SVN In Action(23)      摘要: SVN日常操作基本命令總結
          1. 導入/導出資源:svn import、svn checkout
          2. 更新工作副本: svn update
          3. 添加變化:svn add、svn delete、svn copy、svn move
          4. 檢查變化:svn status、svn diff
          5. 撤銷變化:svn revert
          6. 解決沖突:svn resolved
          7. 提交變更:svn commit  閱讀全文
          posted @ 2009-12-11 18:23 Paul Lin 閱讀(444) | 評論 (0)  編輯
          【原】SVN In Action(22)      摘要: 這時就需要用到SVN提供的清理功能了。清理功能是通過svn cleanup 命令來完成的。當執行這個命令時,SVN會首先完成log文件中沒有完成的剩余工作,釋放鎖定,最后刪除log文件。通常我們都是在項目的根目錄來執行這個命令  閱讀全文
          posted @ 2009-12-11 18:19 Paul Lin 閱讀(352) | 評論 (0)  編輯
          【原】SVN In Action(21)      摘要: 什么時候是Branch?什么時候是Tag?原則如下:

          如果你還需要繼續向目錄提交變更,它就是個分支。如果一旦拷貝后不再提交任何改變哪就是標記。實際上SVN不會強制你不能對名為***tag的目錄進行commit操作,這只是通常上約定。即便因為誤操作我們也可以輕易的使用update操作回滾到當初創建Tag時的快照版本  閱讀全文
          posted @ 2009-12-11 17:39 Paul Lin 閱讀(364) | 評論 (0)  編輯
          【原】SVN In Action(18)      摘要: svn merge的命令用法有三種:
          A.svn merge sourceURL1[@N] sourceURL2[@M] [WCPATH]
          B.svn merge sourceWCPATH1@N sourceWCPATH2@M [WCPATH]
          C.svn merge[[-c M]...|[-r N:M]...] [SOURCE[@REV][WCPATH]]

          Step 1:確定要從哪個版本開始~那個版本結束
          Step 2: 執行集成
          Step 3: 提交集成結果

            閱讀全文
          posted @ 2009-12-11 12:02 Paul Lin 閱讀(454) | 評論 (2)  編輯
          【原】SVN In Action(17)      摘要: svn switch [--relocate] URL。該命令有兩種用法:一種是不使用參數relocate的,一種是使用relocate參數的。它們的使用原則如下:

          A.如果切換后的版本庫路徑還是在同一個版本庫,只是在不同的路徑下。那么使用svn switch URL
          B.如果切換后的版本庫位置已經改變(主機遷移,版本庫遷移),但是目錄結構不變。就需要加relocate參數  閱讀全文
          posted @ 2009-12-10 19:02 Paul Lin 閱讀(395) | 評論 (0)  編輯
          【原】SVN In Action(16)      摘要: 我們看到“創建分支”居然和普通的拷貝動作一摸一樣!是的對SVN來說,主干、分支、標記都是普通的目錄而已,這些都是人為加上的意義。  閱讀全文
          posted @ 2009-12-10 17:04 Paul Lin 閱讀(398) | 評論 (0)  編輯
          【原】SVN In Action(15)      摘要: SVN提供了幾種解決沖突的建議:

          A.(p) postone 延遲解決
          B.(df) diff-full 顯示所有沖突的內容
          C.(e) edit 啟動編輯器解決沖突
          D.(r) resolve 標識沖突已經解決
          E.(mf) mine-full 用我的版本覆蓋他人的修改
          F.(tf) theirs-full 用他人的版本覆蓋我的修改
          G.(l) lanuch 啟動其他工具來解決沖突
          H.(h) help 啟動幫助信息

          雖然SVN提供了比較差異和解決沖突的方法,但避免沖突的最好方法永遠只有一個:明確的分工和良好的溝通,盡量避免多個人同時修改同一份文件。如果不能避免,那么最好指定一個人在提交前負責合并各人的更新,然后一次性提交。  閱讀全文
          posted @ 2009-12-09 23:25 Paul Lin 閱讀(593) | 評論 (0)  編輯
          【原】SVN In Action(14)      摘要: ●使用svn update -r 命令
          ●使用svn copy命令
          ●使用svn cat命令配合重定向  閱讀全文
          posted @ 2009-12-09 17:19 Paul Lin 閱讀(426) | 評論 (0)  編輯
          【原】SVN In Action(13)      摘要: 默認情況下如果svn log不加任何參數,會顯示當前目錄下所有資源的變更歷史,我們可以通過PATH,URL來限定顯示范圍,還可以通過URL PATH來顯示某個URL下的某個(些)文件的變更歷史,甚至還可以指定版本號,版本范圍。

          各種svn log的用法看似復雜,實際上離不開兩樣東西:

          A.資源路徑:本地路徑(PATH)或遠程路徑(URL/URL PATH)
          B.版本號或版本范圍:-r 18:HEAD或者@19
            閱讀全文
          posted @ 2009-12-09 16:01 Paul Lin 閱讀(306) | 評論 (0)  編輯
          【原】SVN In Action(12)      摘要: A.因為SVN為了保護用戶不小心update操作而覆蓋自己本地的修改,不會對已經被修改但尚未提交的資源進行update操作。像這種情況下只能用svn revert而不能用svn update。

          B.和svn update不會對已修改而尚未提交的資源進行update之外,svn del同樣不會刪除已修改但尚未提交的資源---除非你強制加上--force參數。

          C.不要把所有變更都放在最后一次性提交,提交要及時、多次。否則一旦回滾所有其他修改都會跟著撤銷。  閱讀全文
          posted @ 2009-12-09 11:19 Paul Lin 閱讀(553) | 評論 (0)  編輯
          【原】SVN In Action(11)      摘要: 回滾屬性和回滾操作  閱讀全文
          posted @ 2009-12-09 11:00 Paul Lin 閱讀(295) | 評論 (0)  編輯
          【原】SVN In Action(10)      摘要: 實際上svn revert命令是一把“雙刃劍”。它有幾個需要特別小心的地方:

          A.回滾是不可恢復的。由于svn revert回滾的是任何未提交的操作,內容,屬性。所以意味著SVN不會為你保存任何回滾前的歷史版本
          B.回滾是不止于一點而是一段時間的。只要你沒有提交版本,那么不論你多久之前所做的修改都會被回滾,而不僅僅是最近一次的修改  閱讀全文
          posted @ 2009-12-09 09:47 Paul Lin 閱讀(746) | 評論 (0)  編輯
          【原】SVN In Action(9)      摘要: show-updates參數會令客戶端顯示本地工作副本那些文件是out-of-date的。它并不會立即更新本地副本,而是告訴你那些文件會在下次的svn update中被更新  閱讀全文
          posted @ 2009-12-08 21:50 Paul Lin 閱讀(340) | 評論 (0)  編輯
          【原】SVN In Action(8)      摘要: A. svn cat 命令是客戶端命令,在客戶端運行。而svnlook cat 命令是服務器端命令,只能在版本庫所在的機器上運行
          B. svn cat 命令可以查看本地工作副本(PATH)或版本庫(URL)資源的內容,而svnlook cat 命令只能使用REPOS_PATH PATH_IN_REPOS形式  閱讀全文
          posted @ 2009-12-08 17:04 Paul Lin 閱讀(470) | 評論 (0)  編輯
          【原】SVN In Action(7)      摘要: 整個目錄的忽略

          Step 1: 把目錄export到其它目錄下
          Step 2: 把版本庫上的對于目錄刪除并同步到本地
          Step 3: 把原有目錄添加回原來的位置下,并加入SVN ignore列表
          Step 4: 檢查忽略是否生效

            閱讀全文
          posted @ 2009-12-08 16:29 Paul Lin 閱讀(500) | 評論 (0)  編輯
          【原】SVN In Action(6)      摘要: 一次性忽略多個文件:

          Step 1: 在本地任意目錄下創建一個文件,名字假設為ignore.txt
          Step 2: 編輯該文件,添加想要忽略的文件名列表
          Step 3: 通過文件一次忽略多個條目
          Step 4: 提交變更
          Step 5: 檢查忽略是否生效
            閱讀全文
          posted @ 2009-12-08 16:15 Paul Lin 閱讀(541) | 評論 (0)  編輯
          【原】SVN In Action(5)      摘要: 單個文件的忽略:

          Step 1: 把文件備份到其他位置
          Step 2: 把版本庫對應的文件刪除
          Step 3: 從版本庫更新到本地工作副本
          Step 4: 把文件拷貝回原有位置
          Step 5: 把文件添加到SVN的全局屬性svn:ignore
          Step 6: 提交屬性變更  閱讀全文
          posted @ 2009-12-08 14:51 Paul Lin 閱讀(363) | 評論 (0)  編輯
          【原】SVN In Action(4)      摘要: 關于svn add命令我們有2個需要注意的地方:
          A.和svn status命令一樣,svn add命令只能使用PATH,而不能使用URL作為參數
          B.當svn add命令執行完畢后,相關資源并不會馬上立即被加入版本控制中,需要再執行一次commit

          我們需要在每次commit后立即update,已保證我們最新代碼被上傳到版本庫的同時,他人的最新代碼能夠被及時更新到本地  閱讀全文
          posted @ 2009-12-08 11:09 Paul Lin 閱讀(357) | 評論 (0)  編輯
          【原】SVN In Action(3)      摘要: 使用svn info命令可以查看項目版本控制的靜態信息
          使用svn status命令可以查看項目版本控制的實時變更信息  閱讀全文
          posted @ 2009-12-08 10:09 Paul Lin 閱讀(446) | 評論 (0)  編輯
          【原】SVN In Action(2)      摘要: 把項目import到版本庫之后,項目并不會立即就被加入到版本控制中,還需要再從版本庫中check out到本地原有位置才是真正地吧項目加入到版本控制。這一點和TCP/IP協議的三次握手過程類似。必須確保雙方都知道對方的存在和聯系。  閱讀全文
          posted @ 2009-12-07 16:37 Paul Lin 閱讀(414) | 評論 (0)  編輯
          【原】SVN In Action (1)      摘要: 下面我們把svn list和svnlook tree命令的用法總結一下:

          A.svn list PATH:列出PATH對應的版本庫路徑下的目錄內容
          B.svn list URL: 列出URL對應的路徑下的目錄內容
          C.svnlook tree REPOS_PATH:遞歸地列出REPOS_PATH對應的版本庫路徑下的目錄樹內容
          D.svnlook tree REPOS_PATH PATH_IN_REPOS: 遞歸地列出REPOS_PATH下子目錄PATH_IN_REPOS路徑下的目錄樹內容  閱讀全文
          posted @ 2009-12-07 16:12 Paul Lin 閱讀(693) | 評論 (0)  編輯

          <2009年12月>
          293012345
          6789101112
          13141516171819
          20212223242526
          272829303112
          3456789

          常用鏈接

          留言簿(21)

          隨筆分類

          隨筆檔案

          BlogJava熱點博客

          好友博客

          搜索

          •  

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 永康市| 伊宁县| 南江县| 普洱| 新蔡县| 五大连池市| 布拖县| 冕宁县| 页游| 安远县| 阆中市| 江北区| 苗栗市| 策勒县| 娱乐| 共和县| 镇雄县| 石屏县| 云安县| 龙游县| 崇文区| 宜兰市| 临高县| 大庆市| 吉木乃县| 永福县| 建阳市| 察哈| 修水县| 环江| 闽侯县| 昭苏县| 松溪县| 钟山县| 游戏| 盐山县| 商丘市| 犍为县| 特克斯县| 怀安县| 盘山县|