CodeIgniter视图中应包含多少代码? [英] How much code should be in a CodeIgniter view?

问题描述

第一步已完成，某些页面已编码.在查看结果之后，我想到了一个问题...模板(视图)中应该有多少代码?

First steps are done, some pages are coded. And after looking to the result I've got the question... how much code is there should be in templates (View)?

例如，这是一个模板文件:

For example, here is a template file:

<?php $this->load->view('header'); ?>
<?php $this->load->view('banner'); ?>   

<div id="items">
<?php
for($i=0; $i<count($main); $i++) {
    echo '<div class="item">
        <div class="name">'.$main[$i]['name'].'</div>';
    if($main[$i]['icq']=='') { }
        else { echo '<div class="phone">'.$main[$i]['phone'].'</div>'; }
    echo '</div>';
}
?>
</div>

<?php $this->load->view('footer'); ?>

您认为此模板中的代码太多还是正常的?

Do you think there is too much code in this template or it is normal?

推荐答案

第一个答案实际上是正确的，但是用户删除了它(可能是由于同伴的压力).基本上，您不希望模板中包含任何逻辑.在理想的世界中，您具有所有模型数据的标签，但是由于我们在HTML世界中，因此没有标签，因此您必须使用XSLT或使用ViewHelpers.

The first answer was actually spot on, but the user deleted it (probably due to peer pressure). Basically, you do not want any logic in your template. In an ideal world, you had a tag for all the model data, but since we are in an HTML world, there isn't, so you either have to use XSLT or use ViewHelpers.

让我们专注于ViewHelper方法.

Let's focus on the ViewHelper approach.

这很难维护:

<div id="items">
<?php
for($i=0; $i<count($main); $i++) {
    echo '<div class="item">
        <div class="name">'.$main[$i]['name'].'</div>';
    if($main[$i]['icq']=='') { }
        else { echo '<div class="phone">'.$main[$i]['phone'].'</div>'; }
    echo '</div>';
}
?>
</div>

如果将Smarty替换为PHP，情况不会更好.这很容易维护:

And it won't get any better if you replace the PHP with Smarty. This is easy to maintain:

<div id="items">
    <?php echo itemlist($items, 'template.htm') ?>;
</div>

在现在已删除的问题下面，有一个评论员反对此对于非编码人员来说，代码不容易维护，因为他们现在不知道项目清单的定义及其作用." 但这完全是胡言乱语.想一想.

Below the now deleted question, there was a commentor objecting this "code isn't easy to maintain for non-coders because now they don't know where itemlist is defined and what it does." but that's complete gibberish. Think about it for a second.

一方面，他们声称非编码器会遇到一个简单的函数调用问题，但是另一方面，他们希望他们能够理解混合了HTML的PHP​​代码的杂乱无章.设计人员不在乎表示逻辑，而只是在乎实际的表示.输出.

On the one hand, they claim non-coders will have issues with a simple function call but on the other hand they expect them to understand the mishmash of PHP code mixed with HTML. A designer does not care about the presentation logic, but just the actual presentation. The output.

一个简单的函数调用清楚地表明:这是一个项目列表"，比这是一个回显div的for，如果给出了icq可能还有其他东西"要容易得多.函数调用和标签一样好.它具有明确定义的输入和输出.除开发人员外，如何实现输出与其他人无关.

A single function call clearly says: "here be an item list", which is much easier to grasp than "here is a for that echoes a div and maybe something else if icq is given". A function call is as good as a tag. It has clearly defined input and output. How it achieves that output is irrelevant to anyone but the developer.

您的ViewHelper封装了表示逻辑.这是一个片段，您可以在所有视图中重复使用.这比在需要时一遍又一遍地复制并粘贴所有逻辑更容易维护.在上面的示例中，帮助程序有两个参数:

Your ViewHelper encapsulates the presentation logic. It's a snippet you can reuse across all of your Views. That is much more maintainable than copy and pasting all that logic over and over again when needed. In the example above, there is two arguments to the helper:

• $ items是保存实际项目数据的数组或其他可遍历类型
• 'template.htm'是用于呈现数据的模板的文件名

我将第二个选项设为可选，因为我想无论如何它始终是相同的模板.但是由于评论者抱怨非编码者不知道在哪里看，所以我觉得有必要表明告诉非编码者在哪里看是多么容易.

I'll make the second one optional, because I'd assume it's always the same template anyway. But since the commentor complained the non-coder wouldn't know where to look, I felt it necessary to show how easy it is to tell the non-coder where to look.

function itemlist($items, $template = './templates/itemlist.htm') {
    ob_start();
    foreach($items as $item) {
        include $template;
    }
    return ob_get_flush();
}

可能有更有效的方法来解决模板的包含问题.主要思想应该是清楚的.隐藏实际模板中的表示逻辑.您的"template.htm"将如下所示:

There might be more efficient approaches to solve the inclusion of the template. The main idea should be clear though. Hide the presentation logic from the actual template. Your "template.htm" would then look like this:

<div class="item">
    <div class="name"><?php echo $item['name'] ?></div>
    <?php echo contact($item, 'icq' 'phone'); ?>
</div>

否，否则.没有字符串串联或花括号.决定如何联系用户的逻辑也隐藏在ViewHelper中.现在，非编码人员只需知道ViewHelpers的参数即可，这就像知道将哪个属性写入标签一样容易.如有必要，给他们备忘单.

No if and elses. No string concatenations or curly braces. The logic to decide how to the user can be contacted is hidden in a ViewHelper as well. All the non-coder has to know now is the arguments to the ViewHelpers and that's as easy as knowing which attribute to write to a tag. Give them a cheat sheet if necessary.

相关信息:

• http://martinfowler.com/eaaCatalog/templateView.html

编辑

由于下面的两条评论，我决定扩展此答案.以上不是出于抽象的考虑而进行的抽象.用于可重用性和可维护性.我已经在上面指出了这一点，但让我在这里再次解释.

Due to the two comments below I decided to expand on this answer. The above is not abstraction for abstraction's sake. It is for reusability and maintainability. I've already pointed that out above but let me explain that here again.

实际上，我反对使用ViewHelpers很奇怪，因为您将在两个地方都有演示文稿"，但是不会抱怨将页眉，横幅和页脚分开.这是同一件事.您可以隔离可重用的零件，并将其放入自己的模板中.在这一步骤中将逻辑与模板分离只是实现更高的可维护性的自然下一步.

Actually, I find it odd to object to using ViewHelpers because you'll have "have presentation in two places" but not complain about separating header, banner and footer. It's the same thing. You isolate parts that are reusable and put them into their own templates. Separating the logic from the template in that step is just the natural next step to achive even more maintainability.

包含逻辑的视图模板实际上是脚本，而不是模板.任何包含自行组装逻辑的视图模板都注定会重复自身.对于小型站点来说，这可能不是问题，但是如果您正在一个具有数十个甚至数百个视图和小部件的站点上工作，则不对这些部分进行抽象化将导致代码重复.将所有逻辑放到模板中，它将很快变成杂乱无章的C& p标记与条件混合在一起的标记.对于任何重复，更改时间都将加倍.添加内联样式和令人讨厌的Javascript，您将陷入困境.¹

A view template that contains logic is effectively a script and not a template. Any view template that contains the logic to assemble itself is doomed to repeat itself. This might not be an issue with small sites but if you are working on a site with a couple dozen or even hundreds of view and widgets, not abstracting these parts will lead to code duplication. Put all the logic into the template and it will quickly become a tangled mess of c&p'ed markup mixed with conditionals. For any duplication, you'll double the time it takes to change it. Add inline styles and obtrusive Javascript and you are in maintenance hell.¹

如果将OOP用于应用程序的其他部分，那么为什么要在程序中使用程序?如果您知道应该将Javascript和CSS与HTML分开，为什么要将PHP混入模板中?这没有道理. OP的代码段是脚本而不是模板.因此，它是开发人员的领域.因此，您将所有好的做法也应用到应用程序的其他部分.并且包括将逻辑隔离到函数和/或类中.

If you use OOP for the other parts of your application, then why would you go procedural in your view? If you understood that you should separate Javascript and CSS from your HTML, why would you mix PHP into your template? It doesn't make sense. The OP's code snippet is a script and not a template. As such, it is the domain of the developer. And because of that you apply all the good practise you apply to other parts of your application as well. And that includes isolating logic into functions and/or classes.

理所当然的是，正在研究脚本的设计师可能不会立即知道发生了什么.但是话又说回来，一旦您开始添加本机PHP函数，她可能就不知道. mb_strimwidth在做什么?还有substr? ?:的构造是什么?添加的实际PHP越多，非开发人员阅读起来就越困难.

Granted, a designer looking into a script might not immediately know what's going on. But then again, she might not know that either once you start to add in native PHP functions. What's mb_strimwidth doing? And substr? What's that ?: construct? The more actual PHP you add, the harder it will be to read for non-developers.

如果要让设计师处理模板，请不要给他们脚本.给他们模板.如果这样做，则将逻辑与逻辑隔离开来，并用易于掌握的函数调用将其替换.使用可以清楚传达功能用途的功能名称.因此，设计人员仅需要知道我将其与该输入一起使用，我将始终获得该输出.我不在乎该输出将如何.我会将其留给开发人员".

If you want to have designers work on templates, don't give them scripts. Give them templates. And if you do, isolate the logic from it and replace it with easy to grasp function calls. Use function names that clearly communicate what the function does. So the designer only needs to know if "I use this with that input, I will always get that output. I don't care how that output comes to be. I'll leave that to the developer".

将逻辑隔离为函数(或类)还为您带来了直接的优势，即能够测试用于隔离该页面上特定部分的逻辑.您不必设置创建页面所需的整个环境，而只需传递所需的输入并断言它的输出(这就是该函数缓冲字符串而不是将其输出的原因).

Isolating the logic into functions (or classes) also gives you the immediate advantage of being able to test the logic used to render specific parts on that page in isolation. You don't have to setup the entire environment required to create a page, but just pass in the required input and assert it's output (that's why the function buffers the string instead of outputting it btw).

¹^{对于那些认为这不是问题的人，我强烈建议您为自己找到一个遗留应用程序，该应用程序确实将所有逻辑保留在视图模板中.尝试改变一些事情.一旦您有幸享用了2500行意大利细面条代码(每个代码至少包含500个字符)，并且包含重复的PHP，HTML，CSS和JavaScript，您将了解我在说什么.}

这篇关于CodeIgniter视图中应包含多少代码?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！