On 11/9/2010 1:36 AM, spir wrote: > On Tue, 9 Nov 2010 00:17:48 -0500 > "Nick Sabalausky" <a...@a.a> wrote: > >>> People at Facebook told me that the adoption of D inside the company might >>> be helped if they could simply write <?d ... ?> to insert D code into a >>> page. I'm not sure how difficult such a plugin would be to implement. >> >> I'm very suprised by that. That's become considered very bad style by most >> of the [professional] web dev world quite awhile ago, and for very good >> reason. Rails-, django- and even ASP.NET-style "pass variables into an HTML >> template" approaches have proven to be...well...frankly, much less shitty. > > For sure. See "Enforcing Strict Model-View Separation in Template Engines" > http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf > > Denis > -- -- -- -- -- -- -- > vit esse estrany ☣ > > spir.wikidot.com >
I wanted to write a long, detailed reply on this subject, but never got enough time. So I want to write a shorter reply before it's too late. Sorry for the bullet list, I had trouble making it more coherent. 1. You cannot truly enforce Model-View separation by restricting what can be done inside templates. Programmers can still put presentation code inside controllers (and inside other parts of their code), which breaks Model-View separation. 2. There have been many attempts to introduce more or less "pure" templating systems in various languages. PHP has Smarty. ASP has WebForms. The real benefits of such systems just don't live up to the expectations. WebForms, for example, is responsible for creation of many truly horrendous "legacy" systems. They were too restrictive, so programmers resolved to hackish workarounds. In the long run, the developer community responded by creating new template systems (Savant for PHP, MVC/Razor for ASP) that used the host language for templating. 3. The purpose of a templating enging shouldn't be to separate HTML from code. It should be separation of presentation logic from the rest of application logic. And yes, you can do that with restricted templates, but you also can do it with Turing-complete ones. It's possible to create a mess with both of these approaches too. 4. The particular system described in the paper relies on Turing-complete "render" (I would call it pre-render) phase for doing complex processing of data before display. This can be abused just like embedded code is abused. 5. Practical questions should be addressed. If I use templating system A vs B in a real-life environment, which one would result in a more maintainable system design overall? (Having "clean" templates and horrendous mess of hacks that supports it is hardly an achievement, right?) Which one would allow me, while creating real websites, to do my work in less time? Learning curve is not to be sneered at as well. 6. Here are couple of uses cases which I don't think the described system wouldn't handle very well. Let's say you have pagination on your website. Displaying page numbers is clearly a matter of presentation, not controller logic. However, since you can't do any computation in templates, you wouldn't be able to calculate page numbers of interest. Another case is internationalization. Internationalized strings are not "models" that you pass into templates, yet they need to be mutable. There are many solutions to this, but I don't see any of them fitting the system in the paper. ... I'm not arguing in favor of random spaghetti code, but I would argue that in many cases Turing-complete templates are simpler to use without any considerable degradation of maintainability.
