Re: Temple: Compile time, embedded D templates
On Thursday, 2 January 2014 at 10:59:27 UTC, Jacob Carlborg wrote: Nice. Do you have any concept of safe vs unsafe strings? That's a really good idea... [the day passes by] Support implemented in v0.5.0: https://github.com/dymk/temple#filter-policies FilterPolicies allow the developer to insert hooks for when an expression is appended to the buffer. This can be overloaded for different types of expressions, letting concepts like Tainted strings (e.g. your safe vs. unsafe strings) to be implemented. I added an example to the README showing a simple example of this.
Re: Temple: Compile time, embedded D templates
On 2014-01-03 09:39, Dylan Knutson wrote: That's a really good idea... [the day passes by] Support implemented in v0.5.0: https://github.com/dymk/temple#filter-policies FilterPolicies allow the developer to insert hooks for when an expression is appended to the buffer. This can be overloaded for different types of expressions, letting concepts like Tainted strings (e.g. your safe vs. unsafe strings) to be implemented. I added an example to the README showing a simple example of this. Cool :) -- /Jacob Carlborg
Re: Temple: Compile time, embedded D templates
On Thursday, 2 January 2014 at 08:36:24 UTC, Dylan Knutson wrote: The reason for this is that std.variant.Variant isn't CTFEable, because it uses memcpy in opAssign. I'd consider that a Phobos bug; perhaps there is a way to make std.variant CTFE compatible? That'd allow for a much wider (and more useful) range of templates to be evaluated at compile time. I wish Variant worked at compile time myself. Did you file a bug/enhancement request? (I couldn't find one in bugzilla).
Re: Temple: Compile time, embedded D templates
On Friday, 3 January 2014 at 17:50:22 UTC, Nicolas Sicard wrote: I wish Variant worked at compile time myself. Did you file a bug/enhancement request? (I couldn't find one in bugzilla). https://d.puremagic.com/issues/show_bug.cgi?id=11864 Doing some more tests, it seems like just about any template can be evaluated at compile time, if they don't set variables on the context (via var.name, or var(name)). I was surprised to find even filters work for CTFE'd templates!
Re: Temple: Compile time, embedded D templates
On Thursday, 2 January 2014 at 06:59:04 UTC, yazd wrote:
How much of this is done at compile-time?
Strictly speaking, just the generation of the code that writes
the template to the output buffer. E.g, the code above simulating
the Rails form helper would be lowered to code approximately
equivalent to this (but with more fluff to add line numbers, and
expose some needed hooks for the context):
```
void Temple(OutputStream __buff, TempleContext __context = null)
{
//...
//struct FormHelper, etc
//...
// The actual rendering into a buffer code
auto __buff_tmp_0 = form_for(/shorten, , (f) {
__buff.put(Shorten a URL: );
__buff.put(to!string( f.field_for(url) ));
__buff.put(to!string( f.submit(Shorten URL) ));
});
__buff.put(__buff_tmp_0);
auto __buff_tmp_1 = form_for(/person, person, (f) {
__buff.put(Name: );
__buff.put(to!string( f.field_for(name) ));
__buff.put(Age: );
__buff.put(to!string( f.field_for(age) ));
__buff.put(DOB: );
__buff.put(to!string( f.field_for(date_of_birth, date) ));
__buff.put(to!string( f.submit ));
});
__buff.put(__buff_tmp_1);
}
```
I would guess that
the code is compiled but it is evaluated on each render. Is
that correct? Is there a way to force compile-time evaluation
of at least part of the template which does not depend on a
runtime value?
Yes, generated templates themselves can be executed with CTFE
(just had to make a small modification to ArrayOutputAppender,
which has been pushed), as long as they don't take a context. The
reason for this is that std.variant.Variant isn't CTFEable,
because it uses memcpy in opAssign. I'd consider that a Phobos
bug; perhaps there is a way to make std.variant CTFE compatible?
That'd allow for a much wider (and more useful) range of
templates to be evaluated at compile time.
Anyways, here's a working compile time evaluated, compile time
generated template:
```
string templeToString(TempleFuncType* func, TempleContext context
= null)
{
auto accum = new AppenderOutputStream;
(*func)(accum, context);
return accum.data;
}
unittest
{
alias render = Temple!q{
% if(true) { %
Bort
% } else { %
No bort!
% } %
% auto a = capture(() { %
inside a capture block
% }); %
Before capture
%= a %
After capture
};
const result = templeToString(render);
static assert(isSameRender(result, `
Bort
Before capture
inside a capture block
After capture
`));
}
```
Re: Temple: Compile time, embedded D templates
On 2014-01-02 02:12, Dylan Knutson wrote: It didn't before, because of how the semantics of eRuby syntax works, but now it does! It seemed like an important thing to support... Here's an example mimicking a subset of Rails' `form_for` helper: [Snip] Nice. Do you have any concept of safe vs unsafe strings? -- /Jacob Carlborg
Re: Temple: Compile time, embedded D templates
On Thursday, 2 January 2014 at 10:59:27 UTC, Jacob Carlborg wrote: On 2014-01-02 02:12, Dylan Knutson wrote: It didn't before, because of how the semantics of eRuby syntax works, but now it does! It seemed like an important thing to support... Here's an example mimicking a subset of Rails' `form_for` helper: [Snip] Nice. Do you have any concept of safe vs unsafe strings? No, but that's been on the to-do list. I feel like safe vs. unsafe strings are tied heavily with the escaping of unsafe strings, which is specific to a language, so I think the best way to go about this is to provide: - A way to define custom string types (like a struct wrapping a string tracking if it's safe or not) - Callbacks for processing all of the string-ey things written to the output buffer, to decide if something should be escaped or not.
Re: Temple: Compile time, embedded D templates
Added a goodie: Nestable capture blocks (like pseudo-templates
inside your templates)
This template:
```
% auto outer = capture(() { %
Outer, first
% auto inner = capture(() { %
Inner, first
% }); %
Outer, second
%= inner %
% }); %
%= outer %
```
Evaluates to this:
```
Outer, first
Outer, second
Inner, first
```
a-la Rail's capture helper. It was slightly strange to implement,
and means tighter coupling between the template function and a
template context, but I think at this point that's alright, given
the two are yin and yang anyways.
Right now they don't lazily evaluate; would it be desirable for
them to do so?
Re: Temple: Compile time, embedded D templates
On 2014-01-01 12:53, Jacob Carlborg wrote: I was pretty sure that was possible, but apparently it doesn't compile. Reported as: https://d.puremagic.com/issues/show_bug.cgi?id=11855 -- /Jacob Carlborg
Re: Temple: Compile time, embedded D templates
On 2013-12-31 07:05, Dylan Knutson wrote: Hello, A few months ago I had posted a project of mine, templ-d. It was an experiment in writing a template engine for embedding D code in arbitrary text files, a-la Vibe.d's Diet templates, but without the requirement of generating HTML. So, I've revamped templ-d, and written Temple in its place. It supports all the neat stuff that a template engine should, including (but not limited to!) Does it support any kind of helpers, like Rails do? -- /Jacob Carlborg
Re: Temple: Compile time, embedded D templates
On Wednesday, 1 January 2014 at 13:04:27 UTC, Jacob Carlborg
wrote:
On 2013-12-31 07:05, Dylan Knutson wrote:
Hello,
A few months ago I had posted a project of mine, templ-d. It
was an
experiment in writing a template engine for embedding D code in
arbitrary text files, a-la Vibe.d's Diet templates, but
without the
requirement of generating HTML.
So, I've revamped templ-d, and written Temple in its place. It
supports
all the neat stuff that a template engine should, including
(but not
limited to!)
Does it support any kind of helpers, like Rails do?
It didn't before, because of how the semantics of eRuby syntax
works, but now it does! It seemed like an important thing to
support...
Here's an example mimicking a subset of Rails' `form_for` helper:
```d
%
import std.string;
struct FormHelper
{
string model_name;
auto field_for(string field_name, string type=text)
{
if(model_name != )
{
field_name = %s[%s].format(model_name, field_name);
}
return `input type=%s name=%s /`.format(type, field_name);
}
auto submit(string value = Submit)
{
return `input type=button value=%s /`.format(value);
}
}
auto form_for(
string action,
string name,
void delegate(FormHelper) block)
{
auto form_body = capture(block, FormHelper(name));
return `
form action=%s method=POST
%s
/form`.format(action, form_body);
}
%
%= form_for(/shorten, , (f) { %
Shorten a URL:
%= f.field_for(url) %
%= f.submit(Shorten URL) %
% }); %
%= form_for(/person, person, (f) { %
Name: %= f.field_for(name) %
Age: %= f.field_for(age) %
DOB: %= f.field_for(date_of_birth, date) %
%= f.submit %
% }); %
```
Renders:
```
form action=/shorten method=POST
Shorten a URL:
input type=text name=url /
input type=button value=Shorten URL /
/form
form action=/person method=POST
Name: input type=text name=person[name] /
Age: input type=text name=person[age] /
DOB: input type=date name=person[date_of_birth] /
input type=button value=Submit /
/form
```
This change is present in the latest release of Temple
Re: Temple: Compile time, embedded D templates
I've made a post on Reddit, if anyone that found the library nifty would like to upvote: http://www.reddit.com/r/programming/comments/1u71sr/temple_compile_time_embedded_templating_engine/
Re: Temple: Compile time, embedded D templates
On Thursday, 2 January 2014 at 01:12:24 UTC, Dylan Knutson wrote:
On Wednesday, 1 January 2014 at 13:04:27 UTC, Jacob Carlborg
wrote:
On 2013-12-31 07:05, Dylan Knutson wrote:
Hello,
A few months ago I had posted a project of mine, templ-d. It
was an
experiment in writing a template engine for embedding D code
in
arbitrary text files, a-la Vibe.d's Diet templates, but
without the
requirement of generating HTML.
So, I've revamped templ-d, and written Temple in its place.
It supports
all the neat stuff that a template engine should, including
(but not
limited to!)
Does it support any kind of helpers, like Rails do?
It didn't before, because of how the semantics of eRuby syntax
works, but now it does! It seemed like an important thing to
support...
Here's an example mimicking a subset of Rails' `form_for`
helper:
```d
%
import std.string;
struct FormHelper
{
string model_name;
auto field_for(string field_name, string type=text)
{
if(model_name != )
{
field_name = %s[%s].format(model_name, field_name);
}
return `input type=%s name=%s /`.format(type,
field_name);
}
auto submit(string value = Submit)
{
return `input type=button value=%s /`.format(value);
}
}
auto form_for(
string action,
string name,
void delegate(FormHelper) block)
{
auto form_body = capture(block, FormHelper(name));
return `
form action=%s method=POST
%s
/form`.format(action, form_body);
}
%
%= form_for(/shorten, , (f) { %
Shorten a URL:
%= f.field_for(url) %
%= f.submit(Shorten URL) %
% }); %
%= form_for(/person, person, (f) { %
Name: %= f.field_for(name) %
Age: %= f.field_for(age) %
DOB: %= f.field_for(date_of_birth, date) %
%= f.submit %
% }); %
```
Renders:
```
form action=/shorten method=POST
Shorten a URL:
input type=text name=url /
input type=button value=Shorten URL /
/form
form action=/person method=POST
Name: input type=text name=person[name] /
Age: input type=text name=person[age] /
DOB: input type=date name=person[date_of_birth] /
input type=button value=Submit /
/form
```
This change is present in the latest release of Temple
How much of this is done at compile-time? I would guess that the
code is compiled but it is evaluated on each render. Is that
correct? Is there a way to force compile-time evaluation of at
least part of the template which does not depend on a runtime
value? Or is it completely dependant on an optimizing compiler to
do this work?
Re: Temple: Compile time, embedded D templates
On Tuesday, 31 December 2013 at 13:10:53 UTC, Jacob Carlborg
wrote:
On 2013-12-31 07:05, Dylan Knutson wrote:
Hello,
A few months ago I had posted a project of mine, templ-d. It
was an
experiment in writing a template engine for embedding D code in
arbitrary text files, a-la Vibe.d's Diet templates, but
without the
requirement of generating HTML.
So, I've revamped templ-d, and written Temple in its place. It
supports
all the neat stuff that a template engine should, including
(but not
limited to!)
Looks quite nice.
Since you support setting variables in a context using
opDispatch, why no support opDispatch to get the variables as
well? Something like this:
Hello, %= var.name %
And to convert to a specific type:
% if(var.should_bort!bool) {
Ah yeah, I quite like that. I tried to implement the
`var.should_bort!bool` syntax, but I can't pass an additional
type parameter to opDispatch, other than the string of the method
it's dispatching to. Is there a way to do that? Something like
this:
struct Params
{
private:
Variant[string] vars;
public:
T opDispatch(string op, T)() @property
{
return vars[op].get!T;
}
}
Temple: Compile time, embedded D templates
Hello, A few months ago I had posted a project of mine, templ-d. It was an experiment in writing a template engine for embedding D code in arbitrary text files, a-la Vibe.d's Diet templates, but without the requirement of generating HTML. So, I've revamped templ-d, and written Temple in its place. It supports all the neat stuff that a template engine should, including (but not limited to!) - Nested templates (`render` templates within templates) - Layouts that can `yield` to partials - Compile time generation of the template functions, for zero overhead rendering - Writes to an OutputStream (a type of OutputRange), making it compatible with Vibe.d - Easy to work with template contexts, for passing runtime variables to templates. The syntax is based off of eRuby, the templating engine for Ruby on Rails, so it should be very recognizable to the RoR devs here, and very intuitive to use for those who haven't used eRuby before. There's a much more in depth rundown, as well as a plethora of examples, in the README on the project's page, here: https://github.com/dymk/temple dub package: http://code.dlang.org/packages/temple Thanks, and please let me know what you think!
