Alec Thomas wrote:
On Sun, Apr 16, 2006 at 08:08:34PM +0200, Christopher Lenz wrote:
How about passing the resource *object*, e.g. the Ticket or WikiPage
instance?
This is a good idea, but I think the performance impact might be
significant. For example, for TitleIndex to successfully use the
permission system it would need to fetch every wiki page, rather than
just the names. Similarly, if permissions were added for each timeline
provider, each object would need to be fetched to determine
...
I had similar concerns with the TracObject in the xref branch, and there,
I introduced the notion of an object being "loaded" or not.
If a TracObject is created by the way of the `TracObject.factory(type,id)`,
it is very cheap to instantiate, as no db operation will be triggered:
the object will be left in an unloaded state, which is all what is needed
to encapsulate the (type,id) information, as well as to respond to some
identity related methods (e.g. shorname(), displayname()).
In summary, when you do:
obj = TracObject.factory(type, id)
you get the appropriate instance (e.g. a WikiPage, a Ticket) in
the unloaded state, which would be enough for permission related usage.
As a straightforward extension of what I already did, a call to the factory
with an non-registered type could simply result in an instance of TracObject
itself (e.g. when doing TracObject.factory('config', 'plugins')).
I can only encourage you to have a look at:
http://projects.edgewall.com/trac/browser/sandbox/trac-xref/trac/object.py
and, e.g. wiki/model.py or ticket/model.py .
You may also understand better why I think it would be convenient that
a TracObject knows about the client context in which it was created
(i.e. the req),
as many operations could be written in a much simpler way than they are now,
e.g. obj.href(<args>) instead of req.href.<type>(<id>, <args>)
But again, the main reason I think that the correct "context" for an object
(be it a TracObject or the existing WikiPage et al.) should be the client
request rather than directly the environment, is that I see only advantages
at accessing the env objects by going through the request first:
* req.db: the db connection should be obtained from the client request
instead
of directly from the env, as ideally one client request should
correspond
to one transaction.
Not the mention the fact that currently there's some quite convoluted
code
to achieve the exact same thing, only in a "transparent" way.
* req.log: if the log object would be accessed from the req, this would
make it
possible to group related log entries by printing also a request "uid"
* req.config: same thing for the 'config': there are a few config
options (mainly
for customizing appearance) that could be overidden by the user
settings (stored
in the session).
Have a look at MoinMoin settings, to see what kind of options I'm
talking about.
* req.env: lastly, the env should still be accessible, but there would
not be a lot
of usage left (mainly to instantiate Components pseudo-singletons).
Not only would there be the advantages listed above, but the code could
be simplified
a lot by not having to have to give (env, req, (eventually db))
arguments everywhere...
-- Christian
_______________________________________________
Trac-dev mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac-dev
