Apache "mod_d" needs C to instantiate D interpreter?

[Roman Ivanov]

On 11/9/2010 1:36 AM, spir wrote:
> On Tue, 9 Nov 2010 00:17:48 -0500
> "Nick Sabalausky" <a at 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.