www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - embd 0.1.0 - embedded D

reply "Nathan M. Swan" <nathanmswan gmail.com> writes:
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
Mar 06 2013
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
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);
Mar 06 2013
next sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
 
 struct renderEmbd(string FILE, ALIASES...)
 {
 	class Context(R) : emdb.Context {


		mixin(vibe.templ.utils.localAliases!(0, ALIASES));

 		R* _output;
Mar 06 2013
prev sibling parent reply "Nathan M. Swan" <nathanmswan gmail.com> writes:
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
Mar 06 2013
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
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.
Mar 06 2013
parent "simendsjo" <simendsjo gmail.com> writes:
On Wednesday, 6 March 2013 at 19:17:56 UTC, Sönke Ludwig wrote:
(...)

 Actually I plan to start breaking up the vibe-d package into 
 smaller
 functional blocks at some point (...)


Really looking forward to an std.event/async module :)
Mar 06 2013