JWorld@TW the best professional Java site in Taiwan
      註冊 | 登入 | 全文檢索 | 排行榜  

» JWorld@TW » Web Design 版  

按列印兼容模式列印這個話題 列印話題    把這個話題寄給朋友 寄給朋友    訂閱主題
reply to topicthreaded modego to previous topicgo to next topic
本主題所含的標籤
無標籤
作者 關於網站檔案管理 [精華]
aladdin

老婆不准我用兒子照片



發文: 175
積分: 3
於 2003-11-04 13:16 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
先講結論
網站的檔案管理,可以透過(一)善用網站管理軟體,(二)良好的檔案夾架構規劃達成。這篇文章要告訴你這些原則,同時也會告訴你,為何程式人員比設計人員更適合管理網站的檔案——即使設計人員的Dreamweaver或Golive用得比程式人員熟。

狀況與後果敘述
不知道大家有沒有這種經驗:一個網站的開發,先經過設計,然後切圖,最後到了程式。等到兜到一起了的時候,一個簡簡單單的網站,居然可以出現數千多個檔案。再仔細研究,發現很多檔案都是重複的。很可能一個navigation bar的圖檔,在網站裡就放置了七八份。這造成了許多問題:

第一,是maintain的問題。如果客戶要修改圖裡面的文字,你就必須把所有會出現的檔案都一起修改,而這種置換,由於是人工進行(多半是art在處理),常常出錯。如果你的客戶像我一樣,在案子進行的中間就已經這邊翻翻、那邊看看(當網站急著上線的時候,一邊讓業主看東西,一邊進行相關的修改,幾乎是業主一定的要求),鐵定你的account或是PM的日子很難過。

第二,是驗收的問題。遇到一個精明一點的業主(比如像我),這種東西是一定不會驗過的。所以,多半有要求的網站承包者,就得在交貨前,花上許多力氣(一個下午是絕對跑不掉的),一個一個檔案的看過,一個一個連結的解決錯誤。而開發過程中間所引起的誤解,一定更多。

原因
為什麼會發生「相同目的的相同檔案卻在多個地方出現」這樣的狀況呢?

首先,Art在切圖的過程中,如果他不熟悉他的軟體的切圖功能(不論是Macromedia Fireworks或是Adobe Photoshop & ImageReady)這種事就很有可能在儲存切圖的時候發生。這種狀況不在我們這篇文章的處理範圍中,先跳過不計。

第二、更常發生的狀況是:當Art切好圖之後,交給程式。由於沒有事先設立測試網站,或是沒將規矩說清楚,以致於程式人員設立自己的測試環境,或是直接將他工作環境裡臨時設立的檔案夾架構搬到網站上,而產生必須多放一份相關圖檔的狀況。如果你的工作團隊分處多處,這個狀況會非常嚴重。

規劃目的
這個問題事涉開發效能,我們當然需要解決。根本上,我們希望能做到:在整個開發的過程中,都要確保「相同目的」的「相同檔案」,能越少越好,最好是一份。但要如何做到這點呢:一是良好的檔案夾架構規劃,二是善用軟體。由於事前的規劃和軟體所提供的功能也有關,所以,我們得先從第二點開始講起。

解決:善用軟體
不論你今天是用Macromedia Dreamweaver 或是 Adobe Golive,這兩個軟體都有所謂的網站管理功能(別的軟體也許也有,只是我只熟這兩個軟體)。網站的管理功能,基本上包含以下幾件事情:

1.在網站範圍內,會追蹤所有連結指向的檔案,並在使用者更動檔案位置時,自動更新相關的連結。在這裡順道提一下,Golive將HTML中的連結分成兩類:navigational links(或稱hyperlink)和resource link。一般說來,用src標明的就是resource link(如<img>),用href標記的就是navigational links(如<a>)。

2.如果檔案有被其他檔案中的連結指向,而使用者又要刪除該檔案時,程式會提出警告。

3.可以追蹤錯誤的連結,也就是連結所指到的檔案不存在。這個功能還包括提供介面讓人可以很簡單的修改錯誤。Golive在這個方面,做得非常、非常、非常細緻。

4.可以判斷哪些檔案沒有被連結指到,我喜歡稱之為網站的Garbage collection。這個部分,就像GC一樣,也有兩種基本演算法:Dreamweaver使用Reference Count,Golive則使用Mark & Sweep。這個功能多半是產生一個檔案列表,在 Golive裡面你也可以選擇直接刪除,但是我想沒有人會這麼做吧!我的建議是自己做一支程式,把列表中所有的檔案,按照檔案架構,移到另外一個地方,然後用留下來的檔案進行使用者測試。萬一那個檔案還是被需要的,你還可以直接從檔案夾中移回來。

5.第五種,也是最有用的一種:叫做find & replace,嘿嘿!不陌生吧!Dreamweaver與Golive的網站管理功能比一般的編輯軟體強的地方在於:你可以一次對一群檔案做同一個操作(比如一整個網站)。而且,這兩個軟體都有regular expression的操作與代換。只是Dreamweaver的regexp對big5有很嚴重的錯誤(長度計算錯誤導致的selection misplacement),UTF-8有時候也不太正常。

根據以上所說的這些功能,我們可以把所有網站用到的檔案,分成三類。第一類是直接透過HTML的連結定義的檔案。你可以發現,上面的1~4點,都是針對這種連結設計的;也就是說,網站管理軟體的主要功能,就是處理這一類的連結管理。由於這些連結都是在HTML製作完成時,就已經確定身份了。我自己為這類檔案發明了一個名詞:static images。

接下來的第二類、第三類,和透過JSP(或是其他類似的ASP、PHP)或是Javascript改變HTML串流產生的連結有關。如果追究這種連結產生的來源,就會發現分成兩種:第一種,連結是由資料庫中抓取的資料衍生的,比如上稿系統中的內容;另一種,則是因為其他原因而產生的連結。第二種的連結多半和Navigation有關:比如使用Javascript產生的menu bar,rollover image buttons。前面這種從資料庫中抓取資料產生的,我自己稱之為:dynamic images;後面這種,我自己稱之為navigational images。

Dynamic images,這種連結的管理非常簡單——保持不動就對了。如果真的需要修改這部分的連結,那一定會對應到程式的改變——也應該是程式人員處理的部分。Navigational images就比較傷腦筋了,因為多半是application限定的:Dreamweaver產生的,Golive看不懂,反之亦然。如果你是使用自己的javascript來處理這些事情,則這個部分的連結管理,就得完全靠你自己了。

討論到這裡,還有人會問「程式人員比設計人員適合管網站檔案」的理由嗎?

有了這些認識以後,我們就可以開始規劃網站的檔案夾架構。

解決:良好的檔案夾架構規劃
先講結論:把 static images、dynamic images、navigational images分成不同的檔案夾管理。囉裡囉唆了這麼多,要說的其實就是這件事。當然,實際在做的時候,還是有一些guideline的。

1. 全部網站的dynamic images都放在一個檔案夾下,而不要下放到各個application。當然,dynamic images的檔案夾下,還是應該設置各個檔案夾以分別各個application的圖檔。Navigational images也是一樣的處理。

為什麼?因為當網站GC時,所有的dynamic images都會被放入GC列表中。如果你把所有dynamic images放在一個檔案夾下,當GC列表的時候,所有dynamic images,都會被放在一起。你可以很簡單的把列表中的這些檔案移除,或是在移除程式用一個(而不是數十個)參數中跳過這些檔案。

2. 也因為上面這個原因,網站的resource link都應該用網站的絕對路徑(以「/」起頭的路徑)來表示,而非相對路徑。因為在這種原則下,絕對路徑會比相對路徑來得短(相對路徑會多一堆「../」,這還需要解釋嗎?)

3. 為什麼dynamic images與navigational images要分開?dynamic images多半上傳以後就只會新增、刪除,不會修改。Navigational images則是反過來。不同的處理模式,最好還是分開。

先這樣,下次再說。


aladdin edited on 2003-11-05 00:13
reply to postreply to post
» JWorld@TW »  Web Design 版

reply to topicthreaded modego to previous topicgo to next topic
  已讀文章
  新的文章
  被刪除的文章
Jump to the top of page

JWorld@TW 本站商標資訊

Powered by Powerful JuteForum® Version Jute 1.5.8