I think maybe if they pass a function for the global context, it shouldn't take any parameters, that way it isn't limited to where it's used. If they need something from the request, they'll have it "on hand" when they call reply.view right?

Agreed, that will simplify things a bit. Will update accordingly. Thanks for the feedback!

Better?

So I noticed your tests pass query in the context, can you also add a test showing what happens if you've got a query in the path as well as in the global context? Which one can the user expect to be the "winner" in that case?

Sure. If I understand correctly, that only applies to the Vision.handler case, right?

Anywhere were you have access to like the query string or route params. I think that's probably only in Vision.handler, but verify.

Vision.handler does indeed seem to be the only place where request specific artifacts are available. I have added test cases for the relevant cases. The order of precedence (highest to lowest) is:

1. custom handler context
2. route parameters (default handler context)
3. global context

This seems consistent with what I saw in the existing code/tests.

@jagoda somewhere where you do server.inject pass something in the query string. We are trying to test https://github.com/hapijs/vision/blob/master/lib/index.js#L433-L446 to prove what you are saying. We want to engage the hapi code that creates request.query and make sure that it overrides the potential collision with the global context query object.

You'll want to inject a request with a query string and not pass a query as a context value. Make sense?

Yup, understood. I believe I did that here. Sorry if it was unclear that I added a new commit with my previous comment.

Thanks @jagoda!

@jagoda The "Global context" section in the view tutorial should be updated too: http://hapijs.com/tutorials/views#global-context

Should hold off on any documentation updates until the new version is published AND hapi uses it.

@arb no problem. I'm happy to help with documentation when the time comes. @hueniverse I opened #7 to address the style issues.

Feel free to open a PR on hapi with the updated doc and detailed change in the issue notes. The PR should include the change to package.json as well as npm-shrinkwrap.json.

I'd be happy to help with the PR on Hapi once 1.2.0 is published.

I need to fix master to remove the hapi 8 stuff I got in there by accident...

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.