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

Answer 1

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.

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.

Answer 3

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.

Answer 4

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?

Answer 5

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