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