On Sun, 28 Jul 2013 12:37:51 GMT, Dicebot wrote:

Idea is to move from untyped world of user input to strongly typed declarative world of D entities and do all validation in process. That is actually a lot more code but it does scale well. Something like this:

struct UserDescription
{
    string name, password_hash;
    @optional Mail mail;
}

// ...

void handleRegistration(HTTPServerRequest req, HTTPServerResponse res)
{
    UserDescription user;
    try
        user.loadFrom(req.form, req.session, <any possible sources>))
    catch (ValidationException e) // loadFrom stores here information about field that failed validation and description of problem
    {
        render!("register.dt", e)(res); // it is up to Diet template code to chose where to render error message
        return;
    }

    // do stuff, 'user' is guaranteed to be valid here and you only care about application logic       
}

// ...

router.any("/regiser", &handleRegistration);

As you can see, this is fundamentally same exception handling but one may abuse the fact that most web data processing is extremely generic and move all the boilerplate into utility functions (with D introspection power it is damn easy). So that you won't have try-catch for every parameter access but only single one for data access as a whole. It won't be any shorter for small programs but will scale naturally. This snippet may become even better once req.params becomes Variant[string] as because that will allow to split handler into two actual handlers and avoid explicit catching in user code at all.

I actually think vibe.d should be enhanced with such small serialization helpers to make such stuff easy out of the box. vibe.http.form feels too heavy and API-focused for me.

Okay, this looks pretty nice.
I still can't see how you can customise the error response though without a bunch of logic in the catch, and as soon as that exists, then it could equally just appear at the point of consumption.

If this API was available though, I would definitely use it, and say it was a good API.