Hello, Hm, it looks like your answer didn't cover the updated proposal of this morning:
http://trac.edgewall.org/wiki/TracDev/ContextRefactoring#TheResourceclassforresourceidentification (I've sent a mail about it on Trac-dev, but apparently I'm having trouble with my e-mail provider - this one is posted from google groups). There are also a few code samples from the prototype. Now to answer the points: On Sep 27, 7:15 pm, Christopher Lenz <[EMAIL PROTECTED]> wrote: > I stick to my proposal of using a simple list of tuples. Yeah, > "resource descriptors" is a misnomer, let's just call them "resource > identifiers" (as you have done). > > *If* we at some point want to add a project component to the > containment heirarchy, it'd probably just look like this: > > [('project', 'Foo'), ('wiki', ('WikiStart', 1))] > > But to be honest, I'm not sure whether much of our stuff will survive > a move to true multi-project support. Well, another point where we differ. I see a quite clear path from now to multiple project support: http://trac.edgewall.org/wiki/TracMultipleProjects/SingleEnvironment#ProposedImplementation > Furthermore, I think some of the examples for resource identifiers > are bogus. For example, you'll *never* have something like: > > [('wiki', ('WikiStart', 1)), ('query', None), ('ticket', 1))] > > Ticket #1, even if embedded into a wiki page through a query macro or > something, is still an independent resource that is completely > identified by ('ticket', 1). If you think the above example is valid, > you're confusing resource identifiers with the context in which > resources are embedded, which are two separate things that we really > ought not confuse. You're talking about the old Context here, no? Remember that it's mainly because I acknowledged the need for a distinction here that I was willing to make the split between resource identifiers and rendering context. What you describe above is a RenderingContext, which is basically a stack of Resource identifiers. The Resource identifiers themselves have a different notion of parenting (mainly for now: an attachment Resource is a child of e.g. a Wiki Resource). > > Furthermore, I think the argument that we'd need to be creating and > manipulating these things in a generic way very often, which would > demand a more convenient construction/manipulation API, is also > incorrect AFAICT. In many cases, we already have a model object at > hand, and doing something like ticket.identifier to get the resource > identifer is as convenient as it gets. Well, data model instance creation is costly especially in the timeline event providers and search providers, but also in report and query results. > In most other cases, we deal > with just a single-item list, and constructing it via [(realm, id)] > is as simple as it gets. Any other cases (e.g. in the attachment > module) require just a simple list concatenation. ... as long as it stays like that. I find that using simple list manipulation like [-1][0], and this sort of things is error prone and not very future proof (vs. resource.realm, resource.id, resource.version and later maybe resource.project and resource.field if we want that level of detail...) > I would really prefer attempting this "as-lightweight-as-possible" > approach first before trying to come up with some higher-level class- > based design. > Well, it's stays quite light-weight - only a Resource class, no object hierarchy. It's pretty simple. > > > >> = 1. Permissions = > > >> ... > >> cboos raises the point that if the permission system isn't going > >> to be > >> tied to the request object, then there is no reason to use > >> req.perm as > >> the main entry point (other than backwards compatibility). He > >> proposes > >> the rendering context [see below about link rendering] as a > >> possibilty > >> for storing the permission info. Or creating a `User` object to wrap > >> the req.authname and permission cache. > > > Well, actually the PermissionCache is all we need. The fact that it > > is originally attached to 'req' can be safely ignored ;-) > > Right, the cited code was an example, and does not mean you *have* to > access the PermissionCache object through the req. It could have been > passed to you directly, for example. Here we agree. > > > >> = 2. Link Rendering = > > >> ... > > Okay, this area needs more consideration. See the updated proposal and the code samples. But I agree that there's more to it than that, like better mime-type support in the future (re #3332). > >> == 2a. Context Factories and Subclasses == > > Can you enlighten me about where this "summary" is actually needed? > Well, it's perhaps not used right now, I have to check (sorry, I'm a bit short on time). > >> = Appendix R - Resource Class = > > >> cboos's solution to osimons's security suggestion is to run all > >> access > >> to resources through req.perm. Basically add req.perm.resource() > >> that > >> would return the resource if permissions allowed, or raise an > >> error (or > >> return none in the case of req.perm.get_resource()) > > I can't speak for Alec, but I really meant that this whole problem > space is out of scope for 0.11. Permission checks should remain > something that's done in the web interface for the time being. > Well, that's still the case. The permission checks are done nearly the same way as before. > >> Cboos's compromise doesn't look bad, > >> but I think think it's something that would be too rushed for 0.11. > >> Better leave it out and do it properly for 0.12 or 0.13 > > > Well, the point is to discuss a way to do fine grained permission in > > 0.11 until we get it "right", so I don't see how this is rushed... > > Allowing fine grained (i.e. object level) authorization is very > different from adding an API that enforces code to consider > permissions, or even from adding an API that makes it more > convenient. Again, I'm strongly against this kind of thing going into > 0.11, although I do think it'd be important in the long term. Well, I don't really understand your objections here. Can you be more precise, in particular how this would apply to the code samples I supplied? > >> I'm definitely for a very simple > > ... > > read more >> Woops, is that google cutting the quoted text? Anyway, I've run out of time ;-) (discussion to be continued) -- Christian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
