let's use this issue for the discussion about data manipulation per request.
this is a follow up from the discussion started on issue #247
So... one direct way is to attach is to req object - that's guaranteed to be unique per request (at NodeJS layer).
The key issue is how to surface it all the way up to mojito layer..
Can we use another property in ActionContext - say, user-data or something else? This should be merged with the req's property (same name) before it enters the mojito layer (ac).
IMHO, that should be the easiest and, probably, the cleanliest way out!
@gvaish the way I see it, this is just DATA, hence it should be a model not a property under ActionContext. A model that any controller can have access to, collecting the data from it. There are a couple of problems though:
Models (as today, by default) are created per Y instances (which means: per Mojit instances), so really sharing them is not that easy. But we can share the underlaying data between those instances easily through YUI.
Models don't have access to the ActionContext or Req object, which is a problem today in my opinion because we cannot even propagate a cookie to a 3rd party api, or collect data directly from the request, etc. So, in a sense, you will have to propagate the req object from the controller to the model intentionally to be able to capture that data added by the middleware, not trivial.
Model should not have access to the request data.
However, the controller can instantiate an instance of the model, and pass it the request context. But this should be something that the developer chooses to do, not the framework.
Check out the new mojito-data-addon available in 0.5.9pr1. It can expose data as either ac.data.set(name,value) or ac.pageData.set(name, value). For pageData, that info is available to all controllers in the request (once set) and is available to all binders on the resulting page (as mojitProxy.pageData.get(name)).
This is really cool! Thanks @drewfish!
Closing this now that ac.pageData is in place.