On Sunday, December 2, 2012 8:41:49 AM UTC-5, Anthony wrote:
> Also, note that your solution will work specifically when using the
> generic.json view because that view does not require any of the
> response._vars values to be added to response._view_environment (because
> the view processes response._vars directly). But that solution will cause
> rendering of HTML views (and other views that rely on
> response._view_environment) to fail.
I'm not sure that's true. response._vars is set before the lines I
commented out:
if isinstance(page, dict):
response._vars = page
## for key in page:
## response._view_environment[key] = page[key]
This isn't a super-strong proof, but I commented out all 3 instances of the
above in main.py and compileapp.py and so far nothing bad has happened :)
My web site and APIs stil function as they did before. Searching through
all the source of 1.99.7, it isn't obvious where _view_environment is used
to obtain the response variables. I suppose the merging of page / dict
keys into the env might be needed to override environment variables for
some other reason (not obvious to me; you are the expert).
However the risk that someone would innocently return a dict that has keys
in common with the env seems pretty high. The 129 keys include a lot of
common words. I don't think it's practical to restrict the keys allowable
in a dict to render. A lot of times the keys will be data-driven (result
of user input or DB queries) so there isn't a good way to avoid keyword
collisions. This can be a nasty bug since it is data-driven, not syntax or
structural; and will cause an internal error at runtime.
Maybe the above code isn't really necessary? Or if it is necessary, could
it be slightly refactored to distinguish between the "other" kind of dicts
meant to be merged vs. the data-only dicts we might be returning for APIs
and so on? If I knew more about the intended use I would make a more
concrete suggestion but I really don't know enough to do that.
Thanks
--
