Jla框架介紹(三) 資源引用和Sprite模式
前面的一篇文章，我介紹了Jla框架的代碼單元的規范，為什么需要有這樣的規范？最主要的目的還是將能夠將代碼和功能進行有條理的拆分，讓每個代碼單元僅僅關注自身的邏輯，這樣就可以提高代碼的重用性。
可是要真的實現讓每個代碼單元能夠心無旁騖的開始自身邏輯的實現，僅僅有一個框架規范還遠遠不夠，我們必須對一些大部分代碼單元都會關心的問題提供一個合理的解決方案，保證代碼單元不再為這些事情而操心，其中最重要的兩個解決方案是資源管理和配置管理，關于配置的管理，我會在下一篇文章之中講到，本文將首先講到資源管理。
在本框架之中，每個程序是以JavaScript為主體的，但是單靠JavaScript,肯定不能實現那些豐富多彩的應用，對圖片、CSS或者其他資源的調用是很平常的內容，也就是說，一個程序單元(或者說一個類)除了有一個Js文件以外，還有可能有一系列的圖片、CSS片段文件甚至音樂視頻等多方面的內容，這些(統稱為資源文件)和腳本文件合在一起，才組合成為一個程序單元，如果要考慮代碼的重用和獨立性的問題，這些資源文件也應該考慮進去。
對于資源的調用，我設計了這樣的一個解決方案：
1.開發的時候，假設資源文件和類文件一樣，都是分目錄存放的， 例如對于命名空間Com.Test.ClassA,類文件的路徑為：
workspace/src/Com/Test/ClassA.js
假設類ClassA調用了一個圖片test.png,則應該放在：
workspace/resource/Com/Test/ClassA/test.png
這樣，每個類都有自己的資源目錄，將自己的多個資源放在目錄下即可，也不用擔心和其他的文件名沖突的問題
2.假如類ClassA之中想要調用自己的資源，當然不能直接寫路徑（如果直接寫路徑，基本上不能保證代碼部署后或者移動之后還能執行），建議ClassA在定義的時候require Js.Resource類，然后調用該類的靜態方法getUrl,例如：
1 Jla.require(["Js.Resource","namespace.ClassB"],2,function(Resource,ClassB)
3 //code of ClassD start
4 function App()
5 {
6 var img=document.createElement("img");
7 img.src=Resource.getUrl(App,"test.png");
8 }
9 App.prototype.onClick=function()
10 {
11 Jla.require(["namespace.ClassC"],1,function(ClassC)
12 {
13 //調用ClassC.完成點擊之后執行的操作
14 })
15 }
16 //code of ClassD End
17 Jla.set("namespace.ClassD",App);
18 })
在代碼最終部署的時候，資源的訪問路徑和組織形式可能和開發的模式有所不同，這種情況下，只需要在發布的時候通過更改Resource類的配置或者重寫getUrl的方法，就可以讓每個代碼單元正常訪問到自己的資源，各個代碼單元不需要做任何更改。另外，可以根據代碼單元的require關系，完全不需要的代碼單元，其對應資源也不用發布到部署環境之中。
以上就是針對資源的解決方案，該解決方案將代碼單元和資源之間的關系簡單化，帶來很多方便。
下面說說帶來的一個問題，就是Sprite，因為按照現有的框架，我希望能將不同的代碼單元的資源分目錄存放，可是現在很多網站上，將多個圖片(很有可能是毫無關聯)的圖片組合到一張圖片上，這樣，似乎就很難對代碼進行有效的拆分，針對這個問題，我提出如下的解決方案：
首先，我認為，Sprite不應該是開發時就需要考慮的內容，而是部署時需要考慮的內容，因此，我不建議各個代碼單元在開發的時候就使用合并起來的圖片，這樣會大幅度的減少代碼重用性，最好在開發的時候，圖片還是一個個的分離的圖片，每個代碼單元調用自己的資源圖片，哪怕代碼單元內部，也不建議使用Sprite技術，因為我說過：Sprite不應該是開發時就需要考慮的內容，而是部署時需要考慮的內容。
現在假設各個程序單元開發的時候都沒有考慮過Sprite的問題，怎么實現Sprite呢？我想通過這樣一個類似于重寫的技術：
1.假設每個代碼單元，在顯示圖片的時候，都使用一個類Js.Html.Image，這個類提供了create(用來根據URL創建一個圖片實例),setSrc(用來更改一個圖片實例的src),setBackground(用來設置背景圖)三個方法，這三個方法包含了所有圖片的基本使用
2.Js.Html.Image還提供了一個addSprite方法，用于通知Image類，哪些圖片被整合到了另一張圖片的什么地方，例如：
2 {rect:[0,256,300,44],path:Resource.getUrl("Test.Class1","test.png")},
3 {rect:[0,212,300,44],path:Resource.getUrl("Test.Class2","test.png")},
4 ],{size:{x:300,y:300}})
這樣，Image類記錄下這個信息，在創建Test.Class1的test.png圖片的時候，最終實際上會去img/image.png的某一塊上去獲取圖片顯示，這樣就實現了圖片的Sprite方案。
這樣做，我覺得比一般的Sprite方案有更多優點：
1.和開發過程基本無關，使開發過程不受影響，要知道網上討論Sprite技術的時候，一致表明缺點是使開發和維護復雜化
2.假如Sprite圖片做了調整，只需要改上面的配置即可，不需要到處調整。
3.將完全無關的功能組合在一起也完全不是什么問題
這樣就實現了這種模式下的Sprite技術，本來應該將這個關鍵的Image對象源碼展示一下的，但是這個還沒有完善，而且，本系列文章主要是介紹新框架的思路，源碼并不是特別重要，而且，一般寫一個出來也不會太復雜吧。
posted on 2011-01-17 12:05 K_Reverter 閱讀(1618) 評論(5) 收藏 舉報
浙公網安備 33010602011771號