Re: [請益]該如何避免HTML摻雜PHP寫法

看板PHP作者 (Flash)時間11年前 (2012/10/05 12:51), 編輯推噓3(3031)
留言34則, 3人參與, 最新討論串5/6 (看更多)
※ 引述《tkdmaf (皮皮快跑)》之銘言: : ※ 引述《tanson (Flash)》之銘言: : : 寫成物件導向的方式如何,例如: : : class InputGenerator : : { : : static public function select($name, $value, $attr, $options) : : { : : $html = '<select name="' . $name . '">'; : : foreach($options as $key => $option) { : : $selected = ''; : : if ($value == $key) { : : $selected = 'selected'; : : } : : $html .= '<option value="' . $key . '" ' . $selected . '>'; : : $html .= $option; : : $html .= '</option>'; : : } : : $html .= '</select>'; : : return $html; : : } : : } : : 暫且略過$attr html屬性設定的參數 : : 使用時只要 require class至頁面,然後如以下方式 : : InputGenerator::select('name', '1', null, $enums); : : 便可產生所需的下拉選單 : : 不然就是使用framework : : 像是Zend Framework 的view helper : : 讓頁面也乾淨許多 : : 且就不必常使用for迴圈產生元素 : 你這個做法基本上只會造成其他寫程式的人的困擾。 : 同時也帶給美編或是網頁人員設計上的困擾。 : 這次的主題來說最大的問題是在於所謂的「程式」和「頁面」分離的問題。 : 在我的觀念裡,控制行為、資料庫行為……等等的東西的確應該要和頁面分離。 : 但所謂的程式並不是指你用上了「<?php」他就會是程式。 : 以本例必要的重覆html行為,事實上他表明了這是一個做為「連續顯示」的行為。 : 這種情形之下所必要使用的for、foreach、while……等等迴圈行為, : 他仍然只能算是「頁面」的一部份。 : 因為他並不是在控制整個程式走向。 : 而僅僅就為了「輸出」這件事。 : 要不然真的要講到完全程式和HTML分離 : <td><?php echo $row['name']></td> : 這東西豈不就完全違規了? : 適當的view中放置符合於頁面顯示的php code,不僅僅對程式開發人員降低負擔。 : 網頁編輯人員也可以自由的去設計畫面。 : 而不管是網頁人員寫好版面給程式設計師。 : 或是程式設計師先設計醜醜的表單再丟給網頁設計人員去改。 : 都不會有什麼太大的問題。 : 但你包成class來做的話...... : 到底是在給誰難過? : 給我嗎?不會。因為我會把他整個砍掉。 : framework一般的立意就在於MVC架構分離。 : 但是V就叫做VIEW,不叫做「HTML」。 : VIEW不代表他完全不包含任何PHP語法。 : VIEW只是告訴你不要拿來寫程式流程,不要用來取資料庫,不要用來做和「畫面顯示」 : 無關的行為。 : http://www.codeigniter.org.tw/user_guide/general/alternative_php.html : 連codeigniter都有提到關於變換句法的問題。 : 可以合理的理解他們將這幾個php語法視為view的一部份的合理性。 : 不過ci的short tag處理法倒是蠻有趣的。(完全無視伺服器的設定) : (說穿了他不過就是把<?=$name?>在執行前換回<?php echo $name?>罷了) 撇除個人開發 一個團隊在開發新的專案,開發時程是最重要的項目之一 使用物件產生下拉選單等input欄位,可以節省的是甚麼? 節省重複的code撰寫,也就是節省了開發時間 把時間省下多去想流程規劃、物件的設計不是更重要? 再來,如果一個網頁設計師在維護view的時候, 可以看得懂for迴圈產生的select,那為何Class產生出來的select會看不懂 你只要告訴他InputGeneroator::Select() 代表的是下拉選單,和難之有? 且copy一堆php產生的code容易,還是一行code容易且不容易出錯? 更何況現今framework,以ZF為例,使用物件產生出的Input元素 更是百百種,難道您也要說ZF真是罪大惡極? 這樣的產生方式會給人難過嗎?我想答案是不會的 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 210.242.161.16

10/05 13:18, , 1F
節省開發是節省在HTML上真的怪怪的。
10/05 13:18, 1F

10/05 13:18, , 2F
至於code會不會出錯看你有沒有做好單元測試了。
10/05 13:18, 2F

10/05 13:19, , 3F
至於ZF的罪大惡極點……我想就是smarty吧!
10/05 13:19, 3F

10/05 13:19, , 4F
快速的軟體開發不是叫你去節省VIEW方面的東西OK?
10/05 13:19, 4F

10/05 13:20, , 5F
說真的,如果我程式寫好了,HTML的CODE的變動就給網頁人員
10/05 13:20, 5F

10/05 13:20, , 6F
去做。根本沒有什麼開發速度的問題。
10/05 13:20, 6F

10/05 13:21, , 7F
順便告訴你,很多人在用的東西有時只是你不能改變他核心。
10/05 13:21, 7F

10/05 13:21, , 8F
不代表他的思維一定是符合你的需求。
10/05 13:21, 8F

10/05 13:22, , 9F
你要一直提ZF為例,我也可以一直提CI為例。
10/05 13:22, 9F

10/05 13:22, , 10F
你說ZF是用InputGenetoatior::Select()為例的話
10/05 13:22, 10F

10/05 13:24, , 11F
那CI就很簡單的是:我根本就懶的提供。
10/05 13:24, 11F

10/05 13:24, , 12F
CI最多就給你個set_select()就算客氣的了。
10/05 13:24, 12F

10/05 13:25, , 13F
其他像有form_input()、form_textarea()....等等
10/05 13:25, 13F

10/05 13:27, , 14F
簡單來講.... 思維不同.... M$ 的一個asp框架我記得也是提
10/05 13:27, 14F

10/05 13:28, , 15F
供InputGenetoatior::Select()之類的東西去寫。在寫網頁的
10/05 13:28, 15F

10/05 13:28, , 16F
過程中,根本不會寫到HTML、CSS
10/05 13:28, 16F

10/05 13:30, , 17F
可那就變成寫死的東西了。要改的話真的很~~~~~~~~~~
10/05 13:30, 17F

10/05 13:30, , 18F
GOOGLE也推出個GWT,可以在SEVER端完全用JAVA去寫,而不用
10/05 13:30, 18F

10/05 13:31, , 19F
寫javascript,變成直接用java寫JAVA之類的功能
10/05 13:31, 19F

10/05 13:31, , 20F
還是要看使用者啦.....
10/05 13:31, 20F

10/05 13:33, , 21F
ajax 才對 打錯 = =
10/05 13:33, 21F

10/05 13:33, , 22F
我是覺得說,開發這件事真的不是自己爽就好的。
10/05 13:33, 22F

10/05 13:34, , 23F
如果開發網頁,我還得去「教育」網頁人員~~~~~~
10/05 13:34, 23F

10/05 13:34, , 24F
或是我得把我的功能告訴他們怎麼用怎麼放。
10/05 13:34, 24F

10/05 13:34, , 25F
甚至要很緊張的告訴他們:那個千萬別動。
10/05 13:34, 25F

10/05 13:34, , 26F
對自己有什麼好處?
10/05 13:34, 26F

10/05 13:35, , 27F
我常常都跟我公司的網頁人員說一句話:
10/05 13:35, 27F

10/05 13:35, , 28F
我做的東西你就儘量改,改壞了也沒差,反正我主程式不會有
10/05 13:35, 28F

10/05 13:35, , 29F
問題。
10/05 13:35, 29F

10/05 13:35, , 30F
因為我讓他們就是使用基本技術規範的東西就好了。
10/05 13:35, 30F

10/05 13:36, , 31F
其他程式面的問題我自然有其他的處理辦法。
10/05 13:36, 31F

10/05 13:39, , 32F
嗯~ 思維不同~
10/05 13:39, 32F

10/05 13:48, , 33F
是的。思維不同~
10/05 13:48, 33F

10/05 21:24, , 34F
同意tkdmaf說的,我也是不怕美工改~主程式不會有問題
10/05 21:24, 34F
文章代碼(AID): #1GRcSrX9 (PHP)
討論串 (同標題文章)
文章代碼(AID): #1GRcSrX9 (PHP)