最近好久都沒有寫過文章了，主要是這兩個星期都在搞一個問題。在別的大牛看來，可能根本就是小問題，但是確實是花了我兩個星期才搞好。接下來就好好的說下。
首先說下需求情況。數據中的表結構如下：
|
Father |
Son |
|
det |
Forest |
|
det |
Ddc |
|
det |
util |
|
Cmm-uri |
util |
|
sketch |
Cmm-uri |
|
Ddc |
Cmm-f |
|
ddc |
itemmisc |
|
itemmisc |
Core |
|
ddc |
Smonitor |
|
Smonitor |
det |
我們可以看到各種父子關係。如：det->Ddc->Smonitor等,特別注意到這裏還有一個環 det->Ddc->Smonitor->det.這個在真實的數據中是存在的。然後我要得到的結果就是用有向圖來展示這個結構。當然真正的數據要比這個複雜的多，而且數據量也是很多的。
其實這個需求我已經寫過一次文章了。本來我以爲我當時已經完成了的，產生這種想法的原因是我使用的是我自己創建的測試數據。而不是採用真實的數據，這就導致我的複雜性一下子就小了許多。而且貌似性能也不錯。當真實數據上來以後，我發現根本就沒法訪問，而且瀏覽器會卡死。我看了一下源文件的大小，純文本的html文件居然有4M的大小。我師兄看了一下我用的算法，深度優先的遞歸遍歷，就說可能中間有環了。查看數據庫，果真如此。而且展現的方式也需要改變一下，要使用圖結構而不是使用TreeTable的結構。
這個需求就讓我犯難了，我看過很多的圖表框架。畫餅圖、柱狀圖和曲線圖的很多，但是畫有向圖的還是沒見過。想着是自己的見識太少了，就問了問師兄，還真有。他給了我個網址 dracula .這個框剪可以畫出有向圖結構。當時很興奮啊，上來就看了示例，感覺蠻簡單的。就試着寫了個簡單的示例。雖然是可以展示，但是有幾個問題。最大的問題就是不能指定位置，這個框架中的圖節點的位置是通過它自己的算法計算出來的。這讓我感到很是沮喪，沒辦法指定位置，就沒什麼用了。但當時還是不死心，就嘗試着看看框架的源碼，看能不能修改一下。我就發了三天來看源碼，說來慚愧，我硬是沒看明白算法。既然沒得改，就只好找其他的路了。接着就在這個網站上看看了，發現了一個可以可以指定位置的框架。使用起來比原來的還簡單些。
這個是第二個框架的地址 js-graph ,是基於js 和 css的。示例的效果也不錯。然後當時找到這個框架的時候我用的還是測試數據，發現展示起來很方便，所以很輕鬆的將第二版給搞定了。但是一用到真實數據，就發現頁面根本沒有那麼大的空間來放這些圖節點，同時節點節點之間的連接線很多都沒法顯示，看來又是失敗的作品啊。
既然不能一次性全部展示，那麼Ajax可以派上用場了。直接用Ajax+json來處理，發現沒辦法正常的顯示數據。這時，我回過去看看了框架的說明：In order to minimize the work for the user that writes html pages with graphs, I choosed to use
a "declarative strategy", i.e.: rather than ask the user to write javascript code to create the graph, I thought it would be great if he can simply declare that a html element is a node or a connector, or any other kind object involved in the graph So, I decided to rely on css classes for this task in order to keep the document a valid html page and also ease up the definition of objects layout. 看作者都說了,不需要些JS。也就是說沒辦法使用JS動態的添加了。
不過，既然選了就要深入的研究一下。看了源碼以後發現，我動態添加到DOM樹中的東西，被框架給刪除了。也就是，我本來是可以通過JS來添加或者刪除節點的，但是由於框架內部修改了DOM樹，所以直接的添加時不行的。所以又嘗試着修改源碼，這時候測試用的數據就是真實的了，不能老是因爲數據的問題而出問題啊。
使用這個框架時每個節點由兩個部分組成節點<h>標籤(當然也可以用其他的),邊節點<div>.同時還包含一個箭頭的圖片。當頁面載入的時候,框架會獲得這些個節點。節點和邊都有相應的對象Block和Connector，將這些Html標籤用對象來保存。同時還有一些其他的類，大概的結果如下 ：
對於Block對應的HtmlElement他不做其他處理，只是將數據保存。但是對於Connector，就做了很大的手腳。從圖上可以看出,Connector還關聯了兩個類。Segment代表的是連接的線的一段,他將一條連接線分成了三段。ConnectEnd代表的連接線末端的箭頭。他的手腳就動在了這裏。對於一個Connector，他都會創建三個Segment對象和一到兩個ConnectEnd對象。每個Segment都對應了一個新的<div>節點。然後將原來的那個節點刪掉，這樣我本來只添加了兩個節點，被他這麼一搞變成了四個了。我要是再去處理我原來添加進去的節點，根本就不存在了。既然他能夠添加，當然我也可以刪除撒，我給Segment和Connector都增加了一個刪除的方法。將它創建的對象全部刪掉，然後頁面載入的時候重建。這樣是可以了，但是畢竟框架還有很多其他的東西，我這麼刪除肯定會有潛在的bug的。這不我測試的時候顯示三層依賴關係是沒有問題的，但是到了第四層就不行了。刪除的時候頁面上就會顯示殘留的一些邊痕跡，同時其他的連接線就會顯示不正常了。看來還是悲劇了。
使用Ajax的路是走不通了，還是得走頁面刷新的路了。使用頁面刷新，就比較的簡單了。一次性將所有的信息輸出到頁面上就可以了，不過這裏還是要注意環的處理。用遞歸，肯定就要用到棧啊。用棧來保存遞歸路徑上出現的信息，如果第二次出現就不處理了。到這個時候基本上就完成了。看看我走的路，很崎嶇啊。嘗試過很多的框架，很多的方法。其中很多時候我都想直接用Table輸出得了，但是轉念一想，這是自己在公司做的第一個東西，不能就這樣算了。所以還是一直的堅持了下來。最後能夠做完，達到師兄的要求，這點付出還是值得的。
當然，這還沒有完。雖然基本的功能是實現了。但是性能上還需要改進，特別是在數據庫端，我是採用的存儲過程+臨時表的策略實現的。當請求多的時候，頻繁的創建和刪除臨時表對性能的損耗是比較大的。所以還要繼續的改進。
通過這次的過程，是我在選擇使用框架的時候有了新的見識。我不僅要知道框架適合幹什麼，還要知道他不適合幹什麼。特別是適不適合自己的業務需求。如果不能夠適合自己的業務需求，功能再強大也是白搭。我想這也是公司很多的框架都是在原有的框架上進行改進或者乾脆是重新寫一個的原因吧。