added a - almost clean - include #{str_tmpl} feature :D

[UplinkCoder]

Hello,
I added a functions to vibe/templ/diet.d to inject a compile-time generated diet-template into an exsiting template
the code should be fairly obivous.
Could you review it ?
In return I'll add alot of documentation to vibe.d :D
rationals at
http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/10332/
update!
you can now say
enum hello = "h1 Hello World"
stringIncludeRender!("templ.dt",hello)

If the templ.dt looks like this
html
head
title Hello World
body
include #{hello}

you should see Hello World :D

[etcimon]

Can it include-render to an Appender? What about the case where you'd like to include another .dt file? Does this force to use enum = ""; strings?

I'm thinking about creating events with std.events so that some html from multiple libraries can be added at runtime depending on an array of string delegate(...) method that are hooked and called into the res.bodyWriter directly. I think this could do better though if it were possible to have wildcards on the .dt filename and include them as many as they are, in each "views" folder of each dependency in the project.

e.g. I'd want to build a templating library that has every possible position (left, top, right, bottom, etc.), where I can do

div#top
include #{top.*}

And where I can add some dub dependencies to the project like vibe-menu, vibe-search-module, and from it I could have the .dt files: top.menu.dt and top.search.dt, which are automatically compiled into the templating library. Of course, they would also have js.menu.dt and js.search.dt that adds any js to the head of the page in templates and so on. How would that sound?

Naturally this is a rough example, the libraries would have configurations ( I chose Lua for my framework..) where you can decide which domains/routes should include the module or not and so on, but you can see the general idea and I feel you're not to far off from including multiple DT files with wildcards.

[UplinkCoder]

the #{string} syntax is just for stringIncludes, that is the string has to be avilable at compile-time as it is included in before template compilation.
It just means that you can write arbitray strings into a template at compile-time.
Your wildcards have to be already expanded into filenames, before you can write them as a list of include's into your template.
put please clone my vibe.d repo and try it :D

[etcimon]

I'm thinking of something around the lines of

• scan the views folder of each dependency of the compiling project
• use this list of files at compile-time to override each dependency that has DTs with includes
• run a CTFE regex on the file names to resolve the #{top.*} style includes
• loop through the filenames that match, and then import/indent the string contents (CTFE)
• compile the resulting DT template with the included nested data (from other dependencies' DTs)

Does this seem do-able to you? I don't know as much about diet templates but if you confirm maybe I can work on it, I need to try avoiding implementing this as manual delegate handlers with string-based & runtime callbacks.

Maybe the only way would be to add a delegate call at the beginning of each diet template (compiled) call at runtime, where sub-projects' diet template engine can hook with the corresponding dependencies' updated diet template, and override the outdated diet template, with the newer one having populated the #{top.*} style includes.

[UplinkCoder]

Do-able? Yes!
Easy? No.
The problem is at the moment you can you have one string template per diet-file.
The fix is probably trivial, but I just can't get D to iterate a damn static string-array at
compile-time...
Indention by the way is automaticly taken care of string-includes are just like nomal includes they even use the same code.
Includeing a string-include that in turn includes a string include is probebly very hard to maintain ....

[etcimon]

The fix is probably trivial, but I just can't get D to iterate a damn static string-array at
compile-time...

I don't understand what you mean. This works

import std.stdio;
import std.algorithm;

enum str = "some string";

enum splitted = str.splitter(" ");

int main(){
    writeln(splitted);
    foreach (split ; splitted)
        writeln(split);
    return 0;
}

[etcimon]

I agree that a static foreach would be awesome. In the meantime we'll have to do with recursion :/

string genNextEnum(string ident)(string val){

    static foreach (i ; 0..100){
        static if (!__traits(compiles, mixin(ident ~ i))){
            return "enum " ~ ident ~ i ~ " = " ~ val;
        }
    }
}

string genNextEnum(string ident, int i)(string val){
    static if (i >= 100)
        return "";

    static if (!__traits(compiles, mixin(ident ~ i))){
        return "enum " ~ ident ~ i ~ " = " ~ val;
    } else
        return genNextEnum!(ident, i+1)(val);
}

This is an attempt at making a semi-dynamic array with enums, static foreach doesn't work :/

http://forum.dlang.org/thread/[email protected]#post-mailman.1542.1339895489.24740.digitalmars-d:40puremagic.com

My thought is that compiled diet templates and their raw counterparts with the templated arguments could be sent to an enum with the ident being the dt filename and compiled by the main project with the #{top.} part filled in using __traits(compiles, mixin("ctRegex(top.)") ) with some sort of ctRegex for enum existence...

[UplinkCoder]

please let's do futher discussions at either the rejectedsoftware or dlang forum
I don't read pull requests too often :D
http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/10332/
maybe here ?

[etcimon]

sure

[UplinkCoder]

Finished ...
I found a template from bearophile that does exactly what I need.
!!It's now possible to include multiple stringTemplates per file!!

[UplinkCoder]

I guess it's now mergeble

[UplinkCoder]

@s-ludwig is there any reason not to merge it ?

[s-ludwig]

Sorry, still catching up with a lot of github/forum stuff, it will take a little more time until I can make proper review/reply. One thing that would be good though would be if you could squash+rebase against the latest master, so that the history gets cleaned up.

[UplinkCoder]

Will do.
But I feel the stringIncludeRender is abit clumsy.
Also my changes duplicate alot of code, because I didn't wanted to change your functions.
Any suggestions for a better API ?
I would with your approval add pure to many parser functions ...

[UplinkCoder]

Ahm I did something wrong while rebaseing I guess
Well this is embarresing

[s-ludwig]

Ahm I did something wrong while rebaseing I guess

It looks like just the pull request now points to your master branch instead of the stringTemplate one. Not sure if that can be edited afterwards or if a new pull request needs to be opened. I'll go through the commit in your branch and add some comments.

[mihails-strasuns]

Not sure if that can be edited afterwards or if a new pull request needs to be opened.

New one needs to be open. One of absolutely terrible GitHub misfeatures, you can edit pretty much anything in PR but the base branch.