RejectedSoftware Forums

Sign up

Pages: 1 2 3

creating a diet-template at compile time

Hello,

I recently wanted to automaticlly generate a diet-template at compile-time.
I generate a string like

"select (name='Enum1')
option(value='OP1') OP1"

and I want to add this to an existing dt-file.
eg.
...
form (name=form1)
... INSERT HERE

select (name='Enum1')
option(value='OP1') OP1

...

How would I do that ?

Re: creating a diet-template at compile time

@Sönke Ludwig
if there is no such functionality,
would it be okay if I hacked vibe.templ.diet.DietCompiler ?

Re: creating a diet-template at compile time

I played abit with the vibe.d codebase,
and I have to say it is really nice!

Greetings Uplink_Coder

Re: creating a diet-template at compile time

On Thu, 23 Jan 2014 21:46:43 GMT, Uplink_Coder wrote:

I played abit with the vibe.d codebase,
and I have to say it is really nice!

Greetings Uplink_Coder

Sorry for the late answer, I'm still busy with some important bug hunting.

In your pull request, you have modified the language to accept stringinclude - I'd keep the change to a pure API change and instead automatically append ".dt" to the string_include_name, so that include can be used. Other than that, I was wondering if it would be possible to support multiple string based "files" in compileStringIncludeDietFile. Maybe using an alias template parameter that points to either a, let's say, CustomDietFile struct, or to an array of them, where this struct contains the name and contents of the virtual file.

I'd also like to put some thought into the naming scheme of the public functions (BTW, I'm thinking about renaming render!() to renderDiet!(), too). But other than that I think this is a valuable feature to add, and I seem to remember that this has been asked for before.

Regards,
Sönke

Re: creating a diet-template at compile time

I hacked the implementaion together last night.
what API would you suggest ?
I thgout about adding a boolean template parameter to compileDietFile
which is true for strings and false for files ....
I'd the diet-syntax import #{stringvarible}, but I'm teribble at parsers
and I didn't know how to hook into ... escapedHTMLString ... was it I belive.

Re: creating a diet-template at compile time

I'd keep the change to a pure API change and instead automatically append ".dt" to the string_include_name, so that include can be used.

about that ... vibe.d itself is wonderfully flexible but this parser is full of magic strings and numbers!

(lnstr.startsWith("include ") )  ret ~= lnstr[8 .. $].ctstrip() ~ ".dt"; 

is horrible

(lnstr.startsWith(Keyword.include~" ") )  ret ~= lnstr[Keyword.include.length+1 .. $].ctstrip() ~ defaultExt;

would be so mich nicer

Regards,
Uplink_Coder

Re: creating a diet-template at compile time

for stringTempates to seamlessly fit in I need the ALIASES avilable.
once this is sorted out the rest is a breeze.

However to recursivly use stringTemplates it will have to be a 2pass-parser
....

Re: creating a diet-template at compile time

On Fri, 24 Jan 2014 13:42:42 GMT, Uplink_Coder wrote:

for stringTempates to seamlessly fit in I need the ALIASES avilable.
once this is sorted out the rest is a breeze.

However to recursivly use stringTemplates it will have to be a 2pass-parser
....

I'm continuing this discussion about support for multiple includes.
https://github.com/rejectedsoftware/vibe.d/pull/480

The idea is to be able to compile multiple diet templates into multiple diet templates of a project's dependencies. E.g. to have a templating library with a diet template that has left, right columns, and be able to add a calendar library or poll library that add to this same menu in aforementioned template library's diet template.

The idea I have for this is to simulate an enum dynamic array and compile the diet templates into that. The final project could then use filenames that point to where it should be included, e.g. include #{top.*} would fetch filenames with ctRegex that are top.menu.dt and top.search.dt from two other dependencies. Those would be in enum topmenu; enum topsearch; Here's a proof of concept of a compile-time semi-dynamic array of strings.

import std.stdio;
import std.algorithm;
import std.file;
import std.conv;

enum str1 = "dt1";
enum str2 = "dt2";
enum str3 = "dt3";
enum str4 = "dt4";
enum str5 = "dt5";

string genNextEnum(string ident, int i = 1,string val = "")(){

static if (!__traits(compiles, mixin("writeln(" ~ ident ~ i.to!string() ~ ")"))){
    return "enum " ~ ident ~ i.to!string() ~ " = \"" ~ val ~ "\";";
} else static if (i < 100)
    return genNextEnum!(ident, i+1, val)();
return "";

}

string listEnums(string ident, int i = 1)(){

static if (i < 100 && __traits(compiles, mixin("writeln(" ~ ident ~ i.to!string() ~ ")"))){
	return ident ~ i.to!string() ~ ", " ~ listEnums!(ident, i+1)();
}
return "";

}

mixin(genNextEnum!("str", 1, "dt6")());

int main(){

mixin("writeln(" ~ listEnums!("str")() ~ ");");

}

Re: creating a diet-template at compile time

@etctimon

my stringTemplats work like this :
somewhere in your diet template there is an a line "include #{this_string}"
now if you render this template normally you will get
#{thisstring}.dt could not be found
or something like that. If you use my stringIncludeRender like this:

stringIncludeRender!("real_template_on_disc.dt",some_array,other_stuff,this_string);

the line include #{thisstring} in your template will be replaced by the string thisstring.
this
string has to be (or rather contain) valid diet-template syntax.
thisstring will be parsed before the realtemplateondisc.dt!

makeing sure that this_string contains valid code is your responsebility.
please use it and report any bug you find :D

Re: creating a diet-template at compile time

Until I have fixed my code and multiple string-includes are possible
you can get away with

string genIncludeString(string[] filenames) 
{ Appender!string res; 
  foreach(filename;filenames)
    res ~= "include "~filename;

  return res; }


Pages: 1 2 3