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.