To use views or not to use views.

Question

I seem right now to be embroiled in a debate with another programmer on this project who thinks that views have no merits. He proposes a system that PHP looks something like this:

$draw = new Draw;
$nav = $draw->wideHeaderBox().
$draw->left().
    $draw->image().
     Image::get($image,60,array('id'=>'header_image')).
    $draw->imageEnd().
$draw->leftEnd().
$draw->left(10).
    '<div id="header_text">'.
        self::defaultSectionText().
    '</div>'.
$draw->leftEnd().

and so on (this is in the controller btw). Now his arguments for this actually make some sense, he claims that if there is a redesign all we need to do is change the HTML in one place and it changes everywhere automatically. For some reason however, this method still rubs me the wrong way, is there any merit to views over this method? I mean besides not having to retype HTML by hand.

Answer 1

The argument he uses is the argument you need to have views. Both result in only changing it in one place. However, in his version, you are mixing view markup with business code.

I would suggest using more of a templated design. Do all your business logic in the PHP, setup all variables that are needed by your page. Then just have your page markup reference those variables (and deal with no business logic whatsoever).

Have you looked at smarty? http://smarty.php.net

Answer 2

I've done something like that in the past, and it was a waste of time. For instance, you basically have to write wrappers for everything you can already with HTML and you WILL forget some things. When you need to change something in the layout you will think "Shoot, I forgot about that..now I gotta code another method or add another parameter".

Ultimately, you will have a huge collection of functions/classes that generate HTML which nobody will know or remember how to use months from now. New developers will curse you for using this system, since they will have to learn it before changing anything. In contrast, more people probably know HTML than your abstract HTML drawing classes...and sometimes you just gotta get your hands dirty with pure HTML!

Answer 3

Yeah, my mistake, by views I meant templating. Essentially right now the View class uses a rip from Kohana that lets us use straight PHP in our Views. I've looked at Smarty and had some very good experiences with it in the past. Smarty is generally well-documented and I'd actually love to use it. The problem is I just can't seem to make the merits known.

Answer 4

It looks pretty verbose and hard to follow to be honest and some of the code looks like it is very much layout information.

We always try to split the logic from the output as much as possible. However, it is often the case that the view and data are very tightly linked with both part dictating how the other should be (eg, in a simple e-commerce site, you may decide you want to start showing stock levels next to each product, which would obviously involve changing the view to add appropriate html for this, and the business logic to go and figure out a value for the stock).

If the thought of maintaining 2 files to do this is too much to handle, try splitting things into a "Gather data" part and a "Display View" part, getting you most of the benefits without increasing the number of files you need to manage.

Answer 5

I find this is a good technique for view templating.

Answer 6

HTML time-savers are useful, but they're only useful when they're intuitive and easy-to-understand. Having to instantiate a new Draw just doesn't sound very natural. Furthermore, wideHeaderBox and left will only have significance to someone who intimately knows the system. And what if there is a redesign, like your co-worker muses? What if the wideHeaderBox becomes very narrow? Will you change the markup (and styles, presumable) generated by the PHP method but leave a very inaccurate method name to call the code?

If you guys just have to use HTML generation, you should use it interspersed in view files, and you should use it where it's really necessary/useful, such as something like this:

HTML::link("Wikipedia", "http://en.wikipedia.org");
HTML::bulleted_list(array(
    HTML::list_item("Dogs"),
    HTML::list_item("Cats"),
    HTML::list_item("Armadillos")
));

In the above example, the method names actually make sense to people who aren't familiar with your system. They'll also make more sense to you guys when you go back into a seldom-visited file and wonder what the heck you were doing.

Answer 7

I always find it much easier to work directly with html. Theres one less abstraction layer (html -> actuall webpage / php function -> html -> actual webpage) to deal with then you just work in HTML.

I really think the 'just have to change it in one place' thing wont work in this case. This is because they'll be so many times when you want to change the output of a function, but only in just one place. Sure you can use arguments but you'll soon end up with some functions having like a dozen arguments. Yuck.

Bear in mind templating languages / systems often let you include sub templates, allowing you to have some reusable blocks of html.

The bottom line is if I had just started at your company and saw code like that everywhere, my first thought would be, 'Damn it! Need a new job again.'