最近更新: 2007-01-30

PHP 不需要另一個樣版引擎, part 2 - 補充與回應

繼《PHP 不需要另一個樣版引擎》,我再補充一些內容。

PHP 本身就是一個 SGML,XML,HTML 等 markup language document 用的解析器 (parser) ,所以就像一份 XML 文件必須標示 <?xml ?> 一樣, PHP 要求自己包含在 <?php ?> 標籤中。上文說了,這是 SGML 規範內容。儘管我們可以把 PHP 當一個純粹的程式語言,但還是要把 code 放在標籤中。這個怪僻在 Perl, Python, Ruby 中可看不到。

早期瀏覽器尚未內建 XML 引擎時, XML parser 也跟 PHP 一樣是在伺服端工作。現在 XML 內建到瀏覽器了,但 PHP 還沒有。說不定哪天我們就會看到內建 PHP 引擎的瀏覽器了。也許 .Net 版的 PHP (Phalanger) 會搭上微軟 WPF 架構 的順風車,成為第一個被瀏覽器 (Vista/IE only) 內建的 PHP 引擎,用於解析 HTML, XAML 等文件中的 php 標籤。

我認為樣板系統對於如何構成畫面提供了一個一致性的流程與結構,透過學習並使用樣板系統,可以讓程式設計師的工作輕鬆不少,也保證了一定程度的程式品質。 by tokimeki at 2007年01月30日

如果 PHP 身為一個樣版引擎卻不能為 如何構成畫面提供了一個一致性的流程與結構 ,那麼有什麼理由認為再弄另一個樣版引擎,使用另一個樣版語法就可以呢?

還有一個誤解。認為用 PHP 作樣版語法的話,就不能把 View 丟給網頁設計師去做,所以不能減輕程式設計師的工作。我想這是受到不嚴謹的程序員撰寫的雜亂 PHP 程式之誤導而產生的偏差經驗。從語法上來看, Smarty 就比較易讀嗎?前文所舉之例子,可以看出 Smarty 並不見得易讀。而上一個工作經驗告訴我,對一個網頁設計師而言,不管是 PHP 語法還是 Smarty 語法,他們都不會去改。對他們而言,那只是一個單純的、規定的字串,在他們眼中跟一張 Logo 圖檔沒兩樣。他們只會去剪貼、複製那些標籤,再將標籤放在版面的適當位置。

好吧,如果 PHP 不像個樣版引擎,那我們用 XSLT ,道地純正的樣版引擎,而且跟任何程式語言無相依性。然而,我同樣沒碰過哪個網頁設計師真誠地歌頌擁戴 XSLT 。


以下為 2007-01-30 22:10 時增加的補充內容。
其實我想說得是,如果有一位美工人員,願意配合你作畫面的修改,也去學習 PHP 幫你拼版,你覺得這是件好事嗎? by tokimeki

Tokimeki 誤解了。我雖然說用 PHP 做樣版語法即可,但這句話的對象不是網頁設計師,而是程式設計師。會認真看我這文章的人,應該都是程式設計師吧。

對網頁設計師來說,任何樣版語法都是程式設計師弄出來的怪玩意,他們不想理解那是什麼 (本系列文章中第三次說)。他們希望最好在他們的編輯器上,那些 tag 都被當成一個普通的圖示,可以用滑鼠拖放到他們想放的版面位置。像 PHP 在 DreamWeaver 中會顯示成 <php> 的圖示。所以他們可以用滑鼠施放那些圖示到他們想放的位置上,甚至這個簡單的施放動作可以丟給程式設計師去做。

認為網頁設計師可受益於樣版引擎的想法,其實是程式設計師的迷思。我實際的工作經驗告訴我,事實不是如此。因此為何要網頁設計師學習樣版語法呢?別要求網頁設計師去學「任何」樣版語法。樣版這玩意,其實是一種程序性工作,程式設計師才適任。其實 XHTML, CSS 和 XSLT 這三種規範已經很好的告訴我們:把 Layout 和 Style 交給網頁設計師,把 Template 交給程式設計師。

相關文章
樂多舊網址: http://blog.roodo.com/rocksaying/archives/2681202.html

樂多舊回應
未留名 (#comment-3897243)
Tue, 30 Jan 2007 11:54:45 +0800
「有什麼理由認為再弄另一個樣版引擎,使用另一個樣版語法就可以呢?」

JSP 就可以寫 Web 程式,那何必再搞一個 RoR 呢?

這個類比或許不好,但是我想說的是這世界上每個事物其來有自,如果我們有辦法把所有人的開發方式和自己的開發方式統一,那我想這世界上就不會有這麼多軟體的問題了。

或許用技術層面去看這件事情,你的觀點是對的;而我和 tokimeki 會習慣從人的觀點去看,我想我們的差異是在這裡。
未留名 (#comment-3897298)
Tue, 30 Jan 2007 12:18:05 +0800
和 RoR 相比, JSP 不見得適合寫 web 程式。和 PHP 相比, Smarty 並不見得如我們設想的好用。

從技術層面來看,也許我們應該用 XSLT ,而不是 PHP 。所以我應該在這裡鼓吹 XSLT 才對。但我沒這麼做,因為我不是技術狂。事實上,我對技術的採用非常保守。當我覺得應該這麼用的時候,我已經坐在末班車上了。

我也是從人的觀點看事情,也是從人的觀點指出,對網頁設計師來說, Smarty 沒有程式設計師所設想的有用,反正都是程式設計師搞出來的怪玩意,只有你們看得懂。我上次工作的那家軟體公司的網頁設計師如此說。
未留名 (#comment-3897339)
Tue, 30 Jan 2007 12:37:48 +0800
所以我說我們的開發環境很難類比,有人覺得它有用,有人覺得它不好用。我也碰過對 Smarty 感冒的網頁設計,我的方法是...配合他們,所以我自己來。我也碰過用 XSLT 用的很高興的人,不過後來事實證明後面的人根本沒辦法維護。

我其實不打算說服你什麼東西,技術本來就是人所使用的工具,你覺得它不好,我也不會多說什麼。我只是想闡述我的觀點:每個人都會有自己的想法,也有每個人覺得適合自己 (或團隊) 的開發方式,如此而已。

P.S. 另外真是抱歉,我對 JSP 瞭解甚少,這裡是我的謬誤;也許我應該說 Java 的 Web 開發框架才對。我想延伸的觀點是「訂便當」和「黑米」,它們都是好用的服務,但卻是由不同兩個語言及開發框架所發展的。他們的開發者都選擇了適合自己的工具,不管他們是不是「一人團隊」,他們都做到了。
HACGIS@gmail.com(tokimeki) (#comment-3898429)
Tue, 30 Jan 2007 20:21:37 +0800
抱歉,這幾天連續熬夜測試,今天休息到現在才起來吃東西。
其實我想說得是,如果有一位美工人員,願意配合你作畫面的修改,也去學習 PHP 幫你拼版,你覺得這是件好事嗎?

我倒不怕美工人員搞砸,反正我幫人擦屁股習慣了,我擔心的事浪費了這位美工人員的美好時光。

既然有分工上的需要,就應該各盡其力才是,我認為樣板系統對相對整個 PHP 語言來說,範圍小很多,要了解的細節也很有限,這可以降低學習的門檻。不諱言的說,我甚至認為應該專門找個人來作純美工與程式設計師的橋樑,讓他們來作拼版。

即便完全不用樣板系統,實際執行作業時也會訂出一套規則,不符規則的,不論是版面還是程式,都要退回修改。我之前也提過:無規矩不成方圓。這裡的規矩是不論你是套用現有的規則,或是自己設立規則都好,他必須是讓參與的人員都容易學習了解與遵守執行的。

我想這與語言之爭或是什麼樣板系統好不好之類的重要太多!
未留名 (#comment-3898712)
Tue, 30 Jan 2007 22:14:21 +0800
我沒說 Smarty 這類樣版引擎不好,只說 PHP 不需要它們。但 PHP 以外的世界,也許就有 Smarty 發揮的空間。像 Java,C# 這類語言,就用得著。

如果 Smarty 同 XSLT 一樣是獨立於 PHP 之外的樣版引擎,那麼我們的問題就簡單的多,看你喜歡那一種,你就挑哪一種。但 Smarty 偏偏依存於 PHP 且只能用在以 PHP 為開發工具的場合,那麼它的地位就非常尷尬了。

ps.部份回應內容,我補編到正文了。
HACGIS@gmail.com(tokimeki) (#comment-3898940)
Tue, 30 Jan 2007 23:06:54 +0800
我看了你的補述,我的意見跟你相同。
未留名 (#comment-3900017)
Wed, 31 Jan 2007 11:21:20 +0800
自己補充一點團隊工作經驗。雖然說 Layout 和 Style 交給網頁設計師,但一般網頁設計師沒有替 Style 分類與命名的習慣,也不了解這樣做的意義。這一部份需程式設計師要求網頁設計師必須替 Style 取有意義的名稱。

另外,在分工環境下, XSLT 的優點會突顯出來。因為 PHP 或 Smarty 都必須將樣版規則嵌入樣版範本 (網頁設計師丟給程式設計師的網頁) 之中,但 XSLT 不用。 XSLT 可以把樣版規則獨立於樣版範本外,網頁設計師日後若修改過樣版範本,程式設計師不需要重做一次嵌入樣版規則的動作。當然啦,重提是樣版字樣沒有更動;若樣版字樣被改過了,那麼 XSLT 的內容也要跟著修改。但老話一句, XSLT 的語法實在很冗長... 沒有編輯工具幫忙的話,會寫的很痛苦。
未留名 (#comment-4228323)
Tue, 20 Mar 2007 13:03:42 +0800
噗噗,最近剛好因為另一個網站,也關注了這個問題。

我個人比較傾向,有個專門的人去做溝通協調這塊,美術其實只要畫出版面,甚至連Html,CSS也不用會。這種人大概就像是外國的Web Developer,它們通常專注於html,css,javascript,php這些技術。

對於技術背景出身的,對於很多概念本來就容易掌握,而卻忽略了並非所有人都是跟你一樣受過相當的訓練,就像技術人員多數無法製作出好看的作品。所以常常看到很多Framework都會口口聲聲說為了前端的美術設計出一套簡單的專門語法,在Java會有類似JSTL之類的東西。

但我的觀點是不是很讚同讓美術人員花時間去弄html,css,javascript這些東西,效能上不見得比較好,寫這些還是需要比較高邏輯能力的技術人員,所以培養一個專注於有能力將美術設計轉為程式碼的程式設計師比較實在。
未留名 (#comment-4229741)
Tue, 20 Mar 2007 17:32:07 +0800
「卻忽略了並非所有人都是跟你一樣受過相當的訓練」
這是說我嗎?不是吧,我的文章就是要求讓網頁設計師不要去碰底層的語法,只專注於 Layout 和 Style。

我的看法其實和 kuni 是一樣的,那些看似簡便的樣版語法,對網頁設計師來說都是程式設計師搞出來的怪玩意。所以我認為把 Layout 和 Style 交給網頁設計師是趨勢。但我想你可能以為我說的 Layou=要懂HTML, Style=要懂CSS。

冤枉啊,我說把 Layout 和 Style 交給網頁設計師,意思就是要網頁設計師用他們慣用的設計工具,也就是視覺化的平面設計工具去做 layout 和 style 。試想,我連讓網頁設計師去嵌樣版語法都反對了,這麼可能要求網頁設計師直接用底層的 html 和 css 去做 layout 和 style 呢?

嚴格說來,真正一勞永逸的方式是用 XSLT 。因為這是讓程式設計師不用修改 layout 和 style 的文件(就是網頁設計師設計出的範本),就可結合 template 與 layout, style 的方式。
ps.我認為 template 是程式設計師的工作。

可惜 XSLT 實在是舅舅不疼、姥姥不愛,連程式設計師都覺得它很麻煩,寧願自己再搞一套樣版語法。
未留名 (#comment-4234377)
Wed, 21 Mar 2007 10:06:58 +0800
「卻忽略了並非所有人都是跟你一樣受過相當的訓練」- 呵呵,這句不是在說你^^"",指的是擁有技術的人,就是有能力撰寫程式的工程師,工程師會覺得他們創造出來的樣板語法很簡單,認為連一般人都可以輕易上手,但我進一步認為,輕易上手和用的好是兩回事。

為了清楚解釋我的想法,先定義幾個角色,基本上分為(1)美術人員(2)技術人員(技術人員又分網頁程式設計師和元件技術人員)


我將我的想法在清楚的歸納,以開發網頁過程,需要的是
1.整個美術設計(可以想成每一頁是如何呈現,就像是雜誌中的某一頁) 2.將設計轉成程式碼

我的想法是美術人員完成1,用的工具可能是排版工具,也就是出版用的工具(像是Adobe InDesign),網頁不過是一種呈現,我強烈的認為美術人員應該致力於製作出令人讚嘆的版面。

接下來,網頁程式設計師將圖轉換成程式碼,要做的工作是寫好HTML+CSS+Javascript的頁面,並呼叫寫好的function將資料取回來。

元件技術人員要將所有function寫好,讓前端網頁程式設計師直接呼叫即可。

我覺得這樣才是合理的開發流程,這樣美術人員會變的好找,因為它可能是來自別的出版社或是廣告美編,已經熟悉各種出版工具,不會出現徵才條件是熟美術以及網頁製作,天阿。這種人真的很難存在吧,人一天不過才24hr,怎麼有力氣學這麼多,即便是學會,有辦法專精嗎。有時候覺得,企業需要的不是英雄,而是能穩定產出高水準產品的員工,網頁程式設計師的培養和元件技術工程師乍看之下,會認為都是寫程式,覺得程式語言都一樣,但是我認為這根本就是兩個不同的領域了,兩個面對的困難以及其要解決的問題本質上根本不一樣。網頁設計師其實比較不需要懂得寫程式的深層技術,就像是很多進階議題他都不太需要懂得(以Java來說,他不需要去懂Spring, ORM,或是資料庫部分要怎麼實作),他該專注的是所有Web相關的技術,光這個就夠研究了,尤其是現在Javascript終於朝向對的方向前進(像有jQuery這些Framework的出現)。而元件技術師致力於撰寫完善的function讓前端呼叫,專精於尋找更有效率的技術組合。

這樣的分工,其實威力很大,製作出高品質,生產速度快,成本降低也不在是難事,即便是很小的網站,只要一開始詳細的照其任務分工,依照每個位置的專業,越小越簡單的網站反而更賺錢,因為分開後,對專業的人來說都是piece of cake。

哈,會有這種想法其實是我的工作算是元件技術開發,但我卻不是很喜歡鑽研什麼技術之類的,我不喜歡思考這麼多技術上的議題,我喜歡我定義的網頁設計師這個位置。

回到php議題,雖然我初學php,但是我對cake,symfony都無法百分百的認同。不知道你對這些framework有什麼看法

我直覺的想法是,web的呈現還是要以html為主體架構,互動式資料(泛指經由操作資料庫所得的資料,或需經複雜運算的資料等)透過呼叫後段寫好的function直接塞入,我記得好像有人提過,將php混合css等類似插件等東西(這個我真的不太會表達)。cake看起來是透過生成組合view,但我覺得這個關係應該是要相反,view的架構要先有,function只是在適當的地方插入。

以上是就個人的觀點提出,並不代表我堅持這些想法,如果有錯誤的想法,期望透過這樣的對話,來更正自己的錯誤。
未留名 (#comment-4234479)
Wed, 21 Mar 2007 10:20:00 +0800
XSLT是很早期的理想。以前也曾被一些介紹這技術的文章之開場白感到莫名的興奮,但是,語法上還是有點噁心。

在Web呈現這部分,我覺得CSS的活用是第一次大躍進,CSS很早就被提出,但是也是到最近才算是成熟的使用它,現在在外國網站到處可看到寫的非常好的CSS,甚至出現了許許多多的收集寫的好的CSS網站,最經典的網站Zen Garden一直到此,網頁的樣式才終於和他的結構得以分離,以前大概都只是喊喊口號,第二次大躍進大概就是javascript的framework興起是一個重要的改變,可以進一步的改善並搭配CSS,例如可以輕鬆的做出圓角的背景效果,天阿,這在早期是需要切割成好幾等份才做得出來。
未留名 (#comment-4240995)
Thu, 22 Mar 2007 10:34:01 +0800
我對網頁程式設計師的看法略有不同。

我認為設計歸設計,程式歸程式。HTML+CSS 屬於平面設計工作;而Template和JavaScript屬於程式設計工作。

現在有許多平面設計工具可以直接將設計內容以 HTML 或者抽象些的XML格式儲存,樣式也可以存成CSS,似乎沒有必要進行「設計轉程式碼」的動作。事實上,這樣的轉換工作非常不方便,將程式設計與頁面設計工作變成了相關性工作,而不是獨立性工作。這有何差別呢?若為相關性工作,就有先後關係形成:要先完成頁面設計,才能進行程式設計;要等程式設計告一段落,才可以再修改頁面設計。講白些,在頁面設計師完成設計工作前,程式設計師無事可作;當程式設計師將頁面轉程式碼並開始設計工作時,頁面設計師也不能修改頁面。

我先前的工作經驗就有這種現象,當頁面設計師完成頁面設計後,就要程式設計師只能套標籤不能動版面;如果動了版面,那麼頁面設計師就沒辦法再修改頁面。

XSLT 雖然不好用,但確實展現了 template, layout, style 三者可隔離不互相干擾的可能性。在它的規範下,頁面設計師應該將頁面設計內容存成 xml與css文件,而程式設計師(或者你說的網頁程式設計師)則是把樣版(template)與程式內容(javascript)寫在 xslt 文件中。你畫你的,我寫我的;你的內容儲存在xml文件、我的內容儲存在xslt文件,互不干擾。最後再將xml文件交由XSLT引擎套上xslt文件後輸出使用者看的html文件。

但 XSLT 是先進概念 (它不是過去的理想,而是未來式) ,目前還缺乏簡便的xslt編輯工具可用。所以現在我們折衷處理,就像我本文說的一樣,把樣版和程式內容都當成頁面設計工具中的tag圖示,讓頁面設計師在不需理會tag圖示內容的情況下剪貼、搬移圖示。儘管如此,我們還是試圖隔離兩者,儘量以 attach 的方式「套上」程式內容,也就是你說的 javascript 的 framework 的作法。

我的 blog 就是這種作法之實作。我沒辦法修改樂多的頁面設計,換句話說,頁面設計和程式設計被堅固地隔離了。但是我還是無中生有地 attach 了很多程式化元件在部落格的頁面上。

提到 PHP 的 framework ,你不需要百分之百認同,只要認同50%就夠了。你只需要確定一件事:哪個 framework 可以最快完成現在這件case。你並不需要尋找一個可以完成各種case的framework。

你對 MVC 的架構理解還不是十分正確。 function (正確地說是 model) 跟 view 是不相干的。 view 的架構如何, model 一點都不在乎。model只負責邏輯流程及資料產出而已。而且一個model方法只應該產生一種資料結果:讀文章內容的 model 方法只產生單一文章的資料;讀文章分類清單的 model方法只產生分類清單的陣列。應該是 view 根據自己需要呈現的內容決定向哪些 model方法請求資料。如果這個 view 需要在頁面左上角顯示張貼者個人資訊、左側邊欄顯示所有文章分類、主區域顯示單一文章內容時,就要分別向三個 model 方法請求 user profile, article catalogs, article 這三種資料。