I’m working on a feature which needs access to the request object when rendering a unit in edx-platform.
My current approach is to add a filter just before rendering of an XBlock scope.
Though we currently have filters within the Vertical rendering pipeline, we do not have the request object in this scope. These filters also wouldn’t get run anywhere we try to render an XBlock outside of the context of a Vertical.
I have created the following PRs to illustrate what I am trying to do and would love eyes / feedback on the approach:
needs access to the request object when rendering a unit
These filters also wouldn’t get run anywhere we try to render an XBlock outside of the context of a Vertical.
Wait - is your goal to access the request when rending a unit page, or when rendering any XBlock in any context?
I’m assuming this is not something you can achieve using a frontend plugin on the unit page?
Are you modifying the response in any way?
Do you need access to the block / blocks or just the request?
For context, in order to complete the transition to MFEs, some of use are working to figure out how we can dramatically simplify the way that XBlocks are rendered. So I want to avoid baking in too many plugin hooks that assume they’ll be rendered in the way they are today. For example, with the proposal I’m working on, no HTML would be returned from the server at all during any part of rendering a unit page nor individual XBlocks.
Often we need to access the request to get some information that was stored there by the middleware classes.
You can call crum.get_current_request from the context of a filter pipeline step (example). I think you can also do it during the xblock rendering if you are doing a custom xblock.
Ooh, this is good to know. Really we just need read/write access to the request object so if we can get that from an existing filter, we’d be good to go
Hey @Felipe. Looking into this more, this is very cool but I don’t think works for our use case. I need both read / write access and this library seems to only give us read access to the request object.
@braden , we specifically need write access to the request object somewhere during a unit render. I didn’t think this would be possible at the Vertical level since we don’t pass the request down to the Vertical block’s student_view where the current filters live.
I like the idea of simplified XBlock rendering which would likely remove our issue (though, this is also a feature we are in the process of trying to ship so likely wouldn’t be able to wait for those changes to come through).
Oops, yes, you’re right. I’m getting my details mixed up!
More specifically, we’re trying to modify the LANGUAGE_CODE value read by our page but only for an individual request. (I was originally trying to find a way to override on the request since this is a higher priority than a user’s language cookie).
The only way I have been able to make this work is to update the context in render_xblock before rendering, thus the reason for the specific positioning of the suggested filter.
