RejectedSoftware Forums

Am 03.06.2012 22:10, schrieb simendsjo:

On Sun, 03 Jun 2012 21:31:13 +0200, Sönke Ludwig
sludwig@rejectedsoftware.com wrote:

Am 03.06.2012 21:05, schrieb simendsjo:

On Sun, 03 Jun 2012 12:13:49 +0200, Sönke Ludwig
sludwig@rejectedsoftware.com wrote:

Actually, now I think this is actually really cool!the request and optionally not call the next injector, but return or
throw an HttpServerError. With this, the system is basically very
similar to node.js' connect framework.

Its now in vibe.templ.utils. I will also refactor some of my code to
use it when I have time.

I don't know any node.js, but it's a very convenient function.
A problem is that you cannot easily get the parameters from the request
handler.
This could be solved by adding an AA containing indexes to parameters by
name:
void f(size_t[string] paramIndexes, Params...)(Request, Response)
A CTFE function / mixin template should be able to take care of adding
the correct indexes and calling the next injector, but I'm not sure this
is a good design :)

This should work:

mixin(localAliases!(0, VARS));

with localAliases as defined in templ.diet.d:

template localAliases(int i, ALIASES...)
{
static if( i < ALIASES.length ){
enum string localAliases = "alias ALIASES["~cttostring(i)~"]
"~__traits(identifier, ALIASES[i])~";\n"
~localAliases!(i+1, ALIASES);
} else {
enum string localAliases = "";
}
}

Also not really pretty but it works and it's just one line.

Ah. I tested using .stringof, but that didn't give me the original
parameter-name.
A problem with this method (If I read it correctly - haven't tried it)
is that it mixes in every parameter to local scope.
This becomes a problem when an injector is changed or a new one added.
Suddenly code that used to work will get "identifier already defined"
errors.

mixin(localAliases!(["param1", "param2"], VARS);

I agree it's not exactly pretty, and will seem very magical, but then
code should be ready to work with a wide variety of injectors without
needing a lot of change.
Perhaps even better; accept a tuple so you don't have to
"assert(typeof(param1))":
mixin(localAliases!(Tuple!(int, "param1", SomeType, "param2")))

So... Type safe, extensible, ugly as hell :)

Maybe something like

param!("param1", Params) = x;

then it would be possible to do

alias param!("param1", Params) param1;

to make it available as a normal variable. Or maybe even using opDispatch:

param!Params.param1 = x;

alias param!Params params;
params.param1 = x;

?

Of course types are only checked as far as the type system forbids
implicit conversions. So accidentially treating a double as an int would
be possible. But I could imagine this may not be too much of an issue in
practice...

A good name for this is also an issue.. "param" is definitely too general.