embd 0.1.0 - embedded D

Sönke Ludwig sludwig at outerproduct.org
Wed Mar 6 11:17:14 PST 2013


Am 06.03.2013 19:08, schrieb Nathan M. Swan:
> On Wednesday, 6 March 2013 at 11:29:51 UTC, Sönke Ludwig wrote:
>> Am 06.03.2013 10:08, schrieb Nathan M. Swan:
>>> Announcing the release of embd, a low-level (i.e. small) API for
>>> embedding D code into text:
>>>
>>> https://github.com/carlor/embd
>>>
>>> It's a bit of an inconvenient API, but it's customizable and gives the
>>> client control in what gets passed to the template.
>>>
>>> I hope some of you find it useful!
>>>
>>> NMS
>>
>> Great, finally something that works for plain text files!
>>
>> I guess a simple wrapper could make it work with a similar interface to
>> vibe.d's Diet templates (slightly ugly with that struct because of the
>> additional range template argument and not tested at all):
>>
>> struct renderEmbd(string FILE, ALIASES...)
>> {
>>     class Context(R) : emdb.Context {
>>         R* _output;
>>
>>         mixin(renderer);
>>     
>>         void write(string content, dchar evalCode){
>>             if (evalCode == '=')
>>                 filterHtmlEscape(*_output, content);
>>             else
>>                 _output.put(content);
>>         }
>>     }
>>
>>     static void opCall(R)(ref R output_range)
>>     {
>>         static Context!R ctx;
>>         if( !ctx ) ctx = new Context!R;
>>         ctx._output = &output_range;
>>         scope(exit) ctx._output = null;
>>         ctx.render!(import(FILE), `!=`, `<%`, `%>`)();
>>     }
>> }
>>
>>
>> Usage:
>>
>> auto dst = appender!string();
>> renderEmbd!("userprofile.embd.html", username, title, biography)(dst);
> 
> Yes, my original intent was to use it in vibe.d projects.
> 
> Should I try to adopt it into vibe.d?
> 
> NMS

Actually I plan to start breaking up the vibe-d package into smaller
functional blocks at some point and the Diet template compiler might
also end up as a separate package, as it also really is a quite generic
module. I think an output range based interface would be great to have,
though.

One interesting option would be to add some *optional* vibe.d support. A
version(Have_vibe_d){} block could be used to e.g. add a UFCS based
possibility to directly render to a HttpServerResponse, similar to the
res.render!() Diet render function. DUB automatically defines Have_*
version identifiers for all packages that are used for the current
project, so this would then automatically be available for vibe.d based
projects without introducing a hard dependency.


More information about the Digitalmars-d-announce mailing list