※ 引述《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