Allow setting locals prior to harp processing

[david-martin]

e.g.

app.get('/search', function(req, res, next) {
  doSearch(req.query.q, function(err, searchResults) {
    res.locals = {
      searchResults: searchResults
    };
    next();
  });
});

app.configure(function(){
  app.use(express.static(publicDir));
  app.use(harp.mount(publicDir));
});

[DTrejo]

+1 I would want to use this.

If this gets the go-ahead, I volunteer to write tests for this if david-martin doesn't feel in the mood :)

Cheers,
D

[david-martin]

@DTrejo can you point me in the right direction for where to start with tests?
I'm a bit rusty on harpjs

[DTrejo]

As I haven't seen anyone comment that this would be a welcome addition, I might consider holding off on putting more effort into this?

As for writing tests for this, I'd probably copy https://github.com/sintaxi/harp/blob/master/test/multihost.js to middleware.js, and then make another folder in the apps/ that has it's own express server, and also a template that it will server. Then I'd hook up a route to that express server which introduces its own locals variables, and renders them into the template through harp, by calling next(). Then, in the middleware.js test file I would assert that the contents of the variables is shown somewhere on the page, using the existing assertion patterns already seen in the multihost.js test file.

Does that kind of make sense? I suspect that this will be more complicated than we expect, as harp sometimes does redirects, and the route you attach to the express server may yield a redirect in harp-land to another route that harp ends up handing (e.g. somethings /hello redirects to /hello/, meaning that if you attached your express route to /hello, it would not work, as another new request is made to /hello/ which is not bound and would not pass the correct locals variables to the template.

What a wall of text, sorry!

Cheers,
D