Open drewfish opened 11 years ago
Since the page obj is probably going to have contextualized stuff (don't know), I will suggest to allow requests to attach a page object into the request object (or potentially req.locals, which is the standard way of doing it in express 3) and then getting mojito.js
to augment that object with more stuff if it exists, or just create a new object.
Well the middleware is actually just as request-specific as the page object (including contextualization).
I'm looking at line 33 of lib/output-handler.server.js
, which is where the page object is created. Right after creating it we could also merge in req.page
(or req.locals
or whatever we want to call it).
Oh hmm... I see what you mean, mojito.js
is pushing data into the page object. That's a little dirty and is being done that way because the output handler doesn't have direct access to the store. However, the output handler does have direct access to the request object, so I argue that the output handler ctor should be responsible (instead of mojito.js) for moving data from req.page[1] to the page object.
[1] ... or whatever we call it
Our current "page" data object is unique to each request, and is a great place to store request-specific objects/data. However, there's no way for middleware to put objects/data into it.