Live mode -- allows one to change non-code parts of diet templates and render at runtime

schveiguy commented 5 years ago

This is a big commit, and lots of stuff to discuss. This is my attempt at satisfying #53.

The idea is simple -- it's very expensive to recompile an entire website based on diet templates when you just want to move around or alter some HTML in your diet code. Let's say you simply want to add a class to an element. This doesn't change anything but a string literal output by the mixin.

Live mode, instead of outputting a string literal, outputs data from a passed in array. This array is generated by parsing the file at runtime. In order to keep everything sane, the code is ALSO parsed again, and if it doesn't match (save for the line number directives), then an exception is thrown. This is stored behind a cache which checks for file modification dates and only does the expensive parsing if any file or dependency is modified.

The code is a bit overzealous when putting in string outputs, which causes problems in some cases (see hacky issues below). But the nice thing about this is that you can add in html ANYWHERE and it just works. For instance:

- if(x)
  - foo(bar);

can be modified and properly updated like:

-if(x)
  p.someclass Hi diet live!
  - foo(bar);

I had to add a LOT of @safe stuff. Mostly because a lot of things in vibe require @safe but CTFE does not! Most of the files that were changed were simply to add safe tags where appropriate.
The deployed executable REQUIRES access to the views directory. At this time, I look at this as a development feature, so I'm not sure it needs to be "clean" in that respect. It's certainly possible to store the parsed strings that happened at compile time and serve those up if the files aren't there.
There are a couple of "hacky" solutions to problems. First is an else statement, which cannot have a string output between the prior curly brace and the else. Therefore, I suppress the string output in that case (I'm just doing matching, but it should be pretty effective). The second case is a return statement. In this case, the compiler complains about the added string output because the statement is unreachable! So I have a slight hack to skip it on the closing curly brace. I hate the way this is done, but again, this is a development tool, so maybe it's ok to require certain leeway here?
This will not work for type definitions in the template (as you cannot output string table data inside the definition).
This will not work for static functions, as the output range would not be available.

There may be more issues, but this is what came up when I ran it against my pretty decent sized code base (31 diet templates with lots of imports and extends).

Please give a cursory look and let me know your thoughts.

schveiguy commented 5 years ago

ping @s-ludwig this is what I was talking about yesterday. To test, just define a version for DietUseLive in your vibe program, and then you should be able to change non-code portions of your views and it should just work.