Hacker News Reader

Comment by barumrho | Hacker News Reader

But now aren't you putting design into logic?

At first I thought this (and even typed out a long explanation of "the reason why you cannot make the assumption that your resulting document will be manipulated with DOM" involving "what if you want to change the presentation layer to PDF"), but then I realized that nowhere did he advocate mixing the DOM manipulation into his other logic; it could just as easily be a completely separate pile of "presentation to HTML" code that was entirely unrelated to the "generate content to present" layer.

Precisely - in fact, if you want to change the output to JSON, you don't need the HTML templates at all. You just use the same code you were going to use to extract the data from your persistence layer and then output it however you want.

Hmm. I do understand what you are saying, but in most cases where you are outputting HTML, how is this really different from using templates? I see templates as a way to reduce redundant code. The examples on the blog post are simple (e.g. removing a node, which is easier with 'if' statement), but it will probably be messier.

Regarding alternative formats like JSON or PDF, I guess you can add a layer there.

First off, let me be clear (as I'm concerned that your bringing up this unrelated "messier" argument is the beginning of me being used as a proxy for the author): I am not generally arguing in favor, I was simply countering that specific argument against. I will now describe why they are different, but I do not want this to be taken as a defense of the method.

The way it is different is that it is an inversion of control inside the template, not that it is changing up the layering. You still have a "construct data" layer and a "present data" later, and you can still swap out the "present data" layer with something unrelated, such as a normal template engine or whatever else you wish to use to generate JSON or PDF.

However, inside the "template", rather than having HTML with embedded logic (where you can almost envision the HTML calling into the logic to insert text or execute flow control at specific points), you instead have logic that manipulates the HTML via DOM, modifying the HTML to contain text at specific points. You could probably even make a compelling argument that these are duals of each other.

I have a sneaking suspicion that for all the worthiness of the principle of separation of concerns, it's impossible to completely decouple presentation and logic -- you're going to either end up having some degree of model-related logic bubble up into the view, or you're going to have some kind of presentation-related logic seep down into the view.

What we've generally done as an industry is accept the former, but I'm not sure whether one is better than the other.

Reply on news.ycombinator.com