Is this overkill, or good use of CakePHP's HTML helper?

Question

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.

Committal

You know what would be cleaner, faster and more succinct? Straight HTML. I can't abide this sort of 1-to-1 syntax substitution. Write your HTML in HTML. Don't shoe-horn in a middle man for the sake of avoiding the dreaded <?php ?> tags. – Ginzburg

Well, speed is no issue. I wrapped the code in microtime calls and the view renders in 0.00459 seconds. – Committal

The instant you need to use any flow control more significant than a ternary, you're (to use the technical term) completely boned. – Sulfonal

Answer 1

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?

Carbamidine

Peppering your code with <?php ?> is what PHP is for: It is a template system. Just keep your controller logic separate from your display logic and your template files should naturally remain pretty clean. – Ginzburg

Sorry, meagar, but I disagree with you. Manipulating how data is viewed is inherent the the View. Remaining faithful to the MVC architecture does not imply code-less views. Keep the business logic out of the view, by all means... but sort, splice, flip, and otherwise manipulate how you want to VIEW your data in the VIEW. – Committal

@meagar: Templating does not mean lots of PHP tags. It could be 100% PHP or 95% HTML with 5% PHP echos. Depends how you want to use it. – Carbamidine

Answer 2

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.

Rootless

Answer 3

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:

1. 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.

2. 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.

3. Absolute flexibility without adding more layers of API.

As a side effect of this, I tend to use the for(): and endfor; 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).

Rupee

I accepted Leo's answer long ago, but since then I've moved toward doing exactly what you describe here. I use the HTML Helper of CakePHP in methods, and plain HTML in templates (except for "dynamic" things like links. Using the HTML helper for links keeps me from having to change all my views when I configure new routes). – Committal

Ah, I should have mentioned that I do use the Form and Html Helpers in my views instead of manually generating forms and links. Also, the __() function for i18n. – Rupee

Answer 4

By using the helpers you are, in a way, future proofing your code. So when HTML5 comes along and the html or head tags 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 div tag.

Espinosa

Answer 5

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.

Weikert

The complexity of data manipulation could easily be handed off to elements or by a custom helper. I have been working like this lately and I have to say - for someone who would rather write php than html - this seems easier to maintain. – Idealism