You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am working on getting something nice together to work with my presentation at dconf, and one of the things I plan to bring up is the slow cycle of modifying a diet template.
In general, any change to a diet template seems to build the entire project again. Which is pretty slow. One of the things PHP and other interpreted languages enjoy is a quick cycle of editing and testing. Obviously, the compiled portion of diet templates (string interpolations and D escapes) needs a recompile, but just changing layout or changing a class should be doable without requiring a recompile
What I'm thinking is that diet's render function could be put in "development" mode, where during compilation, it generates an AA with string lookups to delegates based on the actual D code, and leave everything else to runtime. Then during runtime, the render function actually reads the diet file, and converts it to html at runtime, replacing any D code with the delegate calls (if any delegate call has no equivalent lookup, then it's an error).
For example:
html
body
h3 Hi, #{name} how are you today?
a(href="good") Good
a(href="notgood") Not so good.
Then when you run, if you change it like this, it still works:
html
head
title Simple question
body
h3 Howdy, #{name} what's cookin?
a(href="good") Doin great!
a(href="notgood") Having a bit of a rough patch.
Basically, the #{name} part will invoke a pre-compiled delegate, but the other parts will be translated at runtime. You can still do this with if/loops, as long as you pass a mechanism to get control back to the interpreter for given branches. e.g.:
html
head
- if (optionA)
title Welcome to this application!
- else
title Welcome to the page #{pagename}
Essentially, the if/else statement can be a delegate which takes 2 delegates to run if the if statement is true or false.
I don't know how possible this is, as I'm not sure how the diet compiler works, but it seems really doable I think.
Obviously in development mode, things are going to be slower. But that's OK because you aren't processing high-volume traffic. It will be quick enough, and quicker than recompiling. Then when you are satisfied with the way things look, you rebuild with development mode off, and it goes back to the fully compiled mode.
The text was updated successfully, but these errors were encountered:
ping @s-ludwig I have this working in a prototype. It's actually quite a straightforward change (not as complicated as I originally imagined). But I wanted to ping you on this, because I don't know what is expected from a standpoint of testing. At this point, I think the tests in existence suffice, save for maybe a test specifically for this mode. But it does require reading the filesystem at runtime. I also noticed that DietUseCache doesn't have any tests for it either.
Will be hopefully having a branch/PR to look at by tomorrow.
I am working on getting something nice together to work with my presentation at dconf, and one of the things I plan to bring up is the slow cycle of modifying a diet template.
In general, any change to a diet template seems to build the entire project again. Which is pretty slow. One of the things PHP and other interpreted languages enjoy is a quick cycle of editing and testing. Obviously, the compiled portion of diet templates (string interpolations and D escapes) needs a recompile, but just changing layout or changing a class should be doable without requiring a recompile
What I'm thinking is that diet's render function could be put in "development" mode, where during compilation, it generates an AA with string lookups to delegates based on the actual D code, and leave everything else to runtime. Then during runtime, the render function actually reads the diet file, and converts it to html at runtime, replacing any D code with the delegate calls (if any delegate call has no equivalent lookup, then it's an error).
For example:
Then when you run, if you change it like this, it still works:
Basically, the
#{name}
part will invoke a pre-compiled delegate, but the other parts will be translated at runtime. You can still do this with if/loops, as long as you pass a mechanism to get control back to the interpreter for given branches. e.g.:Essentially, the if/else statement can be a delegate which takes 2 delegates to run if the if statement is true or false.
I don't know how possible this is, as I'm not sure how the diet compiler works, but it seems really doable I think.
Obviously in development mode, things are going to be slower. But that's OK because you aren't processing high-volume traffic. It will be quick enough, and quicker than recompiling. Then when you are satisfied with the way things look, you rebuild with development mode off, and it goes back to the fully compiled mode.
The text was updated successfully, but these errors were encountered: