Context object should have perm info (0.11dev)
osimons
I ran into an issue the other day that got me thinking about the 0.11
Context object.
The issue was to figure out how to render arbitrary wiki markup
without a request object - which was no problem with 0.10 wiki_to_...
() methods. Now with the context and the new security branch, calling
the formatter (via format_to_html()) it will somewhere deep down say
that there is no req.perm to use when rendering links. Essentially I
am trying something like this:
m = format_to_html(Context(env, None), 'Test: [wiki:WikiStart]')
This particular problem is not yet solved (input welcome :-), but the
important thing here is that it got me thinking about the context
object which is becoming very central in much of the source.
I like the idea of the context object. It has the potential to
simplify my interface to the data and logic. However, too often the
context object is just used to package env and req, so that at the
receiving end it is only used as:
env = context.env
req = context.req
... and the code goes about it's business looking up entities in env
and req as it sees fit - and mostly as before, with the increasing
need for accessing req.perm introduced by new security.
In my mind, the context object should be the core entity for
contextual information. From the example above, one should not ask for
req.perm but instead context.perm. Only rarely (and with good reasons)
should model or utility code really need a request object to work with
a resource. That should be kept in the front-end code.
Permissions and username are obvious additions to the context I think
- having the context be some function of the project, the resource,
and in the context of a given user and security policies.
It would be ideal if the context initialisation could override default
rules by passing further keyword args, like:
c = Context(env, req, authname='simon')
Then, regardless of actual values in req I could pass this context
around, and know that everything would work in the context of that
user. Another example would be to pass a custom href and abs_href to
override the defaults fetched usually attached to req and/or env. Or,
as my problem above; if the req object doesn't exist, the perm logic
is automatically fetched elsewhere and added to the context.
A context object with context.authname, context.perm and context.href
would eliminate most uses of req in back-end code.
:::simon
http://www.coderesort.com
osimons
On Aug 27, 2:52 am, osimons <oddsim...@gmail.com> wrote:
> The issue was to figure out how to render arbitrary wiki markup
> without a request object - which was no problem with 0.10 wiki_to_...
> () methods. Now with the context and the new security branch, calling
> the formatter (via format_to_html()) it will somewhere deep down say
> that there is no req.perm to use when rendering links.
Actually, as macros have always received the req object, I suppose it
never really has been safe to render wiki markup outside a request
context...
:::simon
http://www.coderesort.com
Christian Boos
Well, that's historical. I think it's a perfectly valid use case to
render wiki markup outside of the realm of a web request, e.g. off-line
wiki-to-html or wiki-to-xyz batch conversion, data mining, etc.
In Trac 0.10, a Request object was used to carry the template data
(req.hdf), the user information (req.authname) for basic permission
checks, and the req.path_info was extensively used to identify the
resource being processed. In addition, the req was and is still used to
convey the chrome data and probably a few more things.
I tried to move some of those to the WikiContext object, with a bit more
formalism at the level of how a resource was identified (the stack of
realm/id pairs, plus the version info), but again this ended in a mix of
different concerns as the rendering details were grafted on.
So now I'd like to split the Context into a ResourceDescriptor and a
RenderingContext.
The ResourceDescriptor is solely used to identify versioned information
"resources" and must be cheap to build, as opposed to the full-fledged
data model which requires one or several database lookups.
The RenderingContext still takes several responsibilities: who accesses
the information (therefore allowing to filter out the non authorized
bits of information), what is the expected output (mime-type) and other
rendering details specific to the renderer used, most notably which href
to use as a basis when creating URLs.
-- Christian