这是矫枉过正，还是对 CakePHP 的 HTML 帮助器的良好利用？
我刚刚重新格式化了 CakePHP 应用程序的默认布局。我通过将几乎所有内容都放在 html 帮助器方法中来消除尽可能多的内联 html。
这很有趣，但我想知道我从这次练习中获得了什么好处（如果有的话）？
<?php
$output = implode("\n", array(
$html->docType(),
$html->tag('html', implode("\n", array(
$html->tag('head', implode("\n", array(
$html->charset(),
$html->tag('title', 'Title For App'),
$html->css('css', NULL, array('media' => 'screen,print')),
$html->css('print', NULL, array('media' => 'print')),
$html->script(array('cufon', 'jquery','external'))
))),
$html->tag('body', implode("\n", array(
$html->tag('div', $content_for_layout, array('id' => 'wrapper')),
$html->scriptBlock('Cufon.now();')
)))
)), array('xmlns' => 'http://www.w3.org/1999/xhtml'))
));
echo $output;
?>
我想至少它看起来漂亮、紧凑，而且非常可读。在这种情况下我应该注意哪些陷阱？我应该注意任何速度问题吗？
我喜欢它——但我不喜欢。
我想我需要以某种方式令人信服。
如果您想知道，当查看源代码时，内爆会在 html 中放置漂亮的换行符。
I just reformatted the default layout of my CakePHP application. I eliminated as much in-line html as possible by putting almost everything inside the html helper methods.
It was fun, but I'm wondering what benefit I've gained from this exercise, if any?
<?php
$output = implode("\n", array(
$html->docType(),
$html->tag('html', implode("\n", array(
$html->tag('head', implode("\n", array(
$html->charset(),
$html->tag('title', 'Title For App'),
$html->css('css', NULL, array('media' => 'screen,print')),
$html->css('print', NULL, array('media' => 'print')),
$html->script(array('cufon', 'jquery','external'))
))),
$html->tag('body', implode("\n", array(
$html->tag('div', $content_for_layout, array('id' => 'wrapper')),
$html->scriptBlock('Cufon.now();')
)))
)), array('xmlns' => 'http://www.w3.org/1999/xhtml'))
));
echo $output;
?>
I suppose at least it looks nice and compact, and is pretty readable. What pitfalls should I be aware of in this scenario? Should I be aware of any speed issues?
I like it — and I don't.
I guess I need convincing one way or the other.
If you're wondering, the implodes put nice line breaks in the html when viewing the source.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
几年前我在 Google 小组中进行过这样的讨论。最终，您会意识到，在您需要以编程方式操作内容之前，采用哪种方式都没有多大区别 - 然后，如果您采用 HTML 路线，您会发现您的代码中充满了 <代码> &
?>或字符串连接或双引号变量替换。现在，对于许多应用程序，我更喜欢使用更多帮助程序而不是标记来维护应用程序。
有很多 HTML 没有被帮助器覆盖，因此您无法避免混合，但您可以通过尽可能使用帮助器来最大程度地减少复杂性和混乱。当您开始使用表单时，您会收到大量安全信息，并且 ID 和 NAME 的格式按照 CakePHP 喜欢的方式进行。
PHP 和 CakePHP 就是为此而构建的。为什么只使用一半语言或一半框架？
I had this discussion in the Google group some years back. Eventually, you'll realise that it doesn't make a lot of difference which way you do it until you need to programatically manipulate stuff - then, if you went the HTML route, you'll find your code peppered with
<?php&?>or string concatenations or double quote variable substitutions.Now, many applications down the line, I prefer maintaining the ones with more helper than markup.
There is a lot of HTML that isn't covered by helpers, so you can't avoid a mix, but you can minimise complexity and confusion by using helpers wherever possible. When you start using forms, you get a lot of security stuff thrown in and IDs and NAMEs formatted the way CakePHP prefers.
PHP and CakePHP are built for this. Why only use half a language or half a framework?
这样做的不可否认的好处是 100% 正确的语法，因为您已经消除了任何误操作和丢失开始/结束标记的可能性。但根据我的经验，我可以告诉你的是，半年后，阅读和修改这个结构的难度将会增加一倍。插入条件元素也非常困难。您需要在这里求助于三元运算符，这使得事情的可读性更差。
总的来说，我建议使用传统的 HTML/PHP 组合。
The undeniable benefit of this is 100% correct syntax, since you've removed any possibility of fat-fingering and missing open/closing tags. What I can tell you from experience though is that half a year from now, it will be twice as hard to read and modify this structure. It is also really hard to insert conditional elements. You'd need to resort to the ternary operator here, which makes things even less readable.
Overall, I'd recommend to go with a traditional HTML/PHP mix.
我个人对此很矛盾，但是我在使用PHP时选择了HTML+PHP模式。我可以看到两者的优点，但这就是我选择 HTML+PHP 的原因：
PHP 是一种模板语言 - 最好的。作为一种模板语言，我觉得它远远优于任何其他 PHP 模板语言，以及其他语言 Web 框架中的许多模板语言，因为它的灵活性和功能。
如果我使用 Python 或 Java 等语言，我很可能更喜欢您建议的形式 - 但在使用 PHP 时，它并不是完美的解决方案。
您将无法使用许多已开发的用于处理 HTML 本身的工具。您尤其会失去那些熟悉修改 HTML 并且能够在视图本身中进行简单更改的人。
绝对的灵活性，无需添加更多 API 层。
作为其副作用，我倾向于使用
for():和endfor;语法等，并努力不回显 HTML 标签 - 我将重构为避免它（即，除非在助手等内部，否则不使用方法，在这种情况下，我将使用 Html Helper 生成标签，因为在 PHP 类或函数内部包含 HTML 汤看起来很愚蠢：P）。Personally I am conflicted about this, but I choose the HTML+PHP mode when working with PHP. I can see the advantages of either, but this is why I choose HTML+PHP:
PHP is a templating language - the best. As a templating language, I feel it is far superior to any other PHP templating language, and many of the templating languages in other language web frameworks for it's flexibility and power.
If I were working with a language like Python or Java, I'd most probably prefer the form you suggest - but it's just not the perfect solution when working with PHP.
You lose the ability to use the many tools already developed for working with HTML itself. You especially lose the people who are comfortable with modifying HTML and who would be able to otherwise make simple changes in the views themselves.
Absolute flexibility without adding more layers of API.
As a side effect of this, I tend to use the
for():andendfor;syntax, etc, and strive to never echo HTML tags - I'll restructure to avoid it (ie, not using methods unless inside a helper etc, in which case I'll generate my tags with the Html Helper, because it's just dumb looking to have HTML soup inside of a PHP class or function :P).通过使用帮助器，您可以在某种程度上为您的代码提供面向未来的证明。因此，当 HTML5 出现并且新规范中的
html或head标记发生变化时。理论上，您只需更改 html 帮助程序类，所有标记都是 HTML5。然而，相反，您也依赖 Cake 来生成格式良好的标签。尽管这些框架中有很多都是全栈的，但不可避免地在某些领域它们比其他框架处理得更好。您不应期望它们能够支持整个 HTML 标记集。
我个人认为你所做的事情太过分了。我喜欢使用 HTML 帮助程序来处理链接、url 和包含的文件，因为它具有目录映射的优点。但我不使用帮助程序来生成简单的
div标记。By using the helpers you are, in a way, future proofing your code. So when HTML5 comes along and the
htmlorheadtags change in the new spec. Theoretically you just change your html helper class and all your markup is HTML5.However, on the contrary, you are also relying on Cake to generate well formed tags. Although a lot of these frameworks are full stack, there are inevitably some areas they handle better than others. You should not expect them to facility the entire HTML tag set.
I personally think it's overkill to do what you have done. I like using the HTML helpers for links, urls, and included files because of the directory mapping benefits. But I don't use the helpers to generate a simple
divtag.从编程角度来说，这是非常正确的，因为您从未真正构建过字符串。好处是，由于每件事都是一个函数，因此您可以将各种参数传递给它，并将所有逻辑推送到控制器。例如，您的标题可以为每个页面动态生成，然后传递给您的
$html->tag('title', 'Title For App')调用。然而，由于函数调用的数量巨大，我怀疑它的性能不如简单地使用 PHP 循环和回显变量。
Programmatically, that is very correct, because you're never actually building a string. What's nice is that since every thing is a function, you can pass all sorts of parameters to it, and push all logic to your controllers. So your title, for example, could be dynamically generated for every page, and then passed to your
$html->tag('title', 'Title For App')call.However, due to the sheer number of function calls, I suspect it wouldn't perform as well as simply using PHP to loop and echo out variables.