3 weeks ago, I discussed template engine with Goro Fuji(a.k.a Xslate author).
In the process, I noticed D does not have template engine library.
So I wrote the D version of Mustache.

https://bitbucket.org/repeatedly/mustache4d/src

Mustache is a logic-less template.

http://mustache.github.com/

Implementing this library was nice for a change.


P.S.

I don't test on Windows and 64bit Linux...


Masahiro

On 2/24/11 11:57 AM, Masahiro Nakagawa wrote:
> 3 weeks ago, I discussed template engine with Goro Fuji(a.k.a Xslate
> author).
> In the process, I noticed D does not have template engine library.
> So I wrote the D version of Mustache.
> 
> https://bitbucket.org/repeatedly/mustache4d/src
> 
> Mustache is a logic-less template.
> 
> http://mustache.github.com/
> 
> Implementing this library was nice for a change.
> 
> 
> P.S.
> 
> I don't test on Windows and 64bit Linux...
> 
> 
> Masahiro

String templates, nice! This would help a lot with generating e.g. dynamic web pages.

How does it compare to Terence Parr's StringTemplate engine?


Andrei

Am 24.02.2011 18:57, schrieb Masahiro Nakagawa:
> 3 weeks ago, I discussed template engine with Goro Fuji(a.k.a Xslate
> author).
> In the process, I noticed D does not have template engine library.
> So I wrote the D version of Mustache.
>
> https://bitbucket.org/repeatedly/mustache4d/src

would be great to have this available at compiletime - something like an write(ln) with typeckecks and block functionality :)

with a nice inner mixin that generates an frontend for the template-vars
a little bit like the http://www.digitalmars.com/d/2.0/phobos/std_bitmanip.html bitfield! template

example-style refering to your basic.d example

--- basic.mustache ---
Hello {{name:%s}}
You have just won ${{value:%i}}!
{{#in_ca}}
Well, ${{taxed_value:%f}}, after taxes.
{{/in_ca}}
-----------------------

alias MustacheEngine!(string,import("basic.mustache")) My_Special_Template;

void main()
{
    My_Special_Template my_special_template;

    my_special_template.name = "Chris";
    my_special_template.value = 10000;

    auto in_ca_section = my_special_template.in_ca.create();
    in_ca_section.taxted_value = 10000 - (10000 * 0.4);

    write(my_special_template.render());
}

Am 25.02.2011 09:29, schrieb dennis luehring:
> would be great to have this available at compiletime

better said - an at compiletime generated render-code - would be blasting fast because of just combining the template-chunks inside of an huge write - or every type of section

so something like this:

--- basic.mustache ---
Hello {{name:%s}}
You have just won ${{value:%i}}!
{{#in_ca}}
Well, ${{taxed_value:%f}}, after taxes.
{{/in_ca}}
-----------------------

would be mixined/compiled to something like:

class TemplateEngine
{
  mixin( generate template-members/sections/renderer) )
  //section:main
  struct main: section
  --> string name
  --> int value
  --> string mixined_renderer()
  {
    auto writer = appender!string();
    formattedWrite(writer, "Hello %s\nYou have just won $%i!\n%s",name,value,section_in_ca.mixined_renderere());
    return writer.data;
  }

  //struct section_in_ca: sections
  --> in_ca [] blocks;
  string mixined_renderer()
  {
    string tmp;
    foreach( block blocks )
    {
       tmp ~= block.mixined_renderer();
    }
    return tmp;
  }

  //section:in_ca
  struct in_ca
  --> float taxted_value
  --> mixined_renderer
  void mixined_renderer( _writer )
  {
    auto writer = appender!string();
    formattedWrite(writer, "Well, $%f, after taxes.\n",taxed_value);
    return writer.data;
  }

  //.in_ca.create add new in_ca section to the section_in_ca.blocks

  // and section can have inner sections etc....

  string render()
  {
    return main.mixined_renderer();
  }
}

and if its runned to the end you can even check if inputs are const and remove completely the depending code... the idea is to generated to "write"-code as compact as possible

On Fri, 25 Feb 2011 03:43:40 +0900, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 2/24/11 11:57 AM, Masahiro Nakagawa wrote:
>> 3 weeks ago, I discussed template engine with Goro Fuji(a.k.a Xslate
>> author).
>> In the process, I noticed D does not have template engine library.
>> So I wrote the D version of Mustache.
>>
>> https://bitbucket.org/repeatedly/mustache4d/src
>>
>> Mustache is a logic-less template.
>>
>> http://mustache.github.com/
>>
>> Implementing this library was nice for a change.
>>
>>
>> P.S.
>>
>> I don't test on Windows and 64bit Linux...
>>
>>
>> Masahiro
>
> String templates, nice! This would help a lot with generating e.g.
> dynamic web pages.

Thanks!

> How does it compare to Terence Parr's StringTemplate engine?

I never used StringTemplate, so I can't compare Mustache with StringTemplate correctly.
StringTemplate seems to be standard template that has many features, but
I did not mostly use such features in Ruby.

I think Mustache features enough to use general cases(ctemplate is a good example too).
Logic-less approach is safety and makes template file more simple, but it is trade-off.
In a subjective answer, I like "{{#list}}" than "$foreach n in names$".

Of course, I think we need StringTemplate-like library for complex cases.


Masahiro

On Fri, 25 Feb 2011 17:29:53 +0900, dennis luehring <dl.soluz@gmx.net> wrote:

> Am 24.02.2011 18:57, schrieb Masahiro Nakagawa:
>> 3 weeks ago, I discussed template engine with Goro Fuji(a.k.a Xslate
>> author).
>> In the process, I noticed D does not have template engine library.
>> So I wrote the D version of Mustache.
>>
>> https://bitbucket.org/repeatedly/mustache4d/src
>
> would be great to have this available at compiletime - something like an write(ln) with typeckecks and block functionality :)
>
> with a nice inner mixin that generates an frontend for the template-vars
> a little bit like the http://www.digitalmars.com/d/2.0/phobos/std_bitmanip.html bitfield! template
>
> example-style refering to your basic.d example
>
> --- basic.mustache ---
> Hello {{name:%s}}
> You have just won ${{value:%i}}!
> {{#in_ca}}
> Well, ${{taxed_value:%f}}, after taxes.
> {{/in_ca}}
> -----------------------
>
> alias MustacheEngine!(string,import("basic.mustache")) My_Special_Template;
>
> void main()
> {
>      My_Special_Template my_special_template;
>
>      my_special_template.name = "Chris";
>      my_special_template.value = 10000;
>
>      auto in_ca_section = my_special_template.in_ca.create();
>      in_ca_section.taxted_value = 10000 - (10000 * 0.4);
>
>      write(my_special_template.render());
> }

In the old days, I implemented the compile-time template engine using similar approch :)

> In the old days, I implemented the compile-time template engine using
> similar approch :)

the old days (of D)? - why the switch to pure runtime based?

On Fri, 25 Feb 2011 22:04:50 +0900, dennis luehring <dl.soluz@gmx.net> wrote:

>> In the old days, I implemented the compile-time template engine using
>> similar approch :)
>
> the old days (of D)?

A year and a half.

> why the switch to pure runtime based?

When CMS using compile-time template exists, how does user update template file?


Masahiro

Am 25.02.2011 15:26, schrieb Masahiro Nakagawa:
>>  the old days (of D)?
>
> A year and a half.

code available?

>
>>  why the switch to pure runtime based?
>
> When CMS using compile-time template exists, how does user update template
> file?

ok but when used as (for example) debugging help is no need for runtime loading, for example i use templates likes this for graph debugging - but it would be nice to reduce the runtime loading (even my large string) to compile-time :)

On Sat, 26 Feb 2011 01:08:06 +0900, dennis luehring <dl.soluz@gmx.net> wrote:

> Am 25.02.2011 15:26, schrieb Masahiro Nakagawa:
>>>  the old days (of D)?
>>
>> A year and a half.
>
> code available?

No. It was a joke program for me.

>>
>>>  why the switch to pure runtime based?
>>
>> When CMS using compile-time template exists, how does user update template
>> file?
>
> ok but when used as (for example) debugging help is no need for runtime loading, for example i use templates likes this for graph debugging - but it would be nice to reduce the runtime loading (even my large string) to compile-time :)

I agree this point.