Christopher Lenz wrote: >> "A ticket today can be accessed through navigation/request >> to ticket, queries, macros, links and countless other ways. >> In each and every instance I need to remember to check >> permissions. Always. And in the same manner. Some sort of >> custom ticket box macro that gets this wrong will spill all >> the beans." > > I'm not saying the goal isn't worthy, ...
Ok, point taken. > ... > What's the problem with doing this work on a branch (scheduled for > 0.12 or later), leave the application of security restrictions to the > UI code (as it is currently and always has been), and concentrate on > the other issues for now? OK, I can freeze my current approach in an "experimental" branch, for the sake of moving forward and try the "optional" checks approach. >> B. The rendering context >> ... > What I mean that we don't need is, for example, whether a snippet of > wiki text that actually belongs to a ticket or wiki page is being > rendered in the timeline or in the search results, for example. The > only part it needs is to be informed about the resource it belongs to. There's at least one need for this, mentioned in one of the snipped points: preventing "recursive" rendering. Also, the wiki rendering could eventually be different whether we're rendering the resource in its main context or in an embedded one. For example, we could avoid generating the "id" attributes for content headings in the timeline (as this sometimes happen when we render a snippet from new ticket description). > [snip lots] >> - More generally, the rendering context will be used to >> progressively >> get rid of the Request object in the rendering layer, and be used >> to simplify the mimeview API > > Okay, I can definitely see a need for that, so what are you proposing > the rendering context should look like? A RenderingContext object knows about the current resource (.resource) and it's parent context (.parent), which is the one which embeds or wraps the current one. This will later be used to gradually take over the usage of req. For example, it will have a .properties dict which is initially filled with the req.args at the more general level, but those properties can also be specified within code processor blocks in the wiki. Another crucial information is the expected output mimetype. Conveying this information down the rendering chain will e.g. allow a LaTeX macro to avoid going through HTML generation when the output type is precisely LaTeX. Those things are post-0.11, though. Having the .resource and .parent _ and of course still the .req for now _ is all we need. Speaking about the misuse of the req, the recently contributed ShowPath (*) plugin shows that in the new ITemplateStreamFilter we have the same kind of issues we (used to) have in macros: most ITemplateStreamFilter would probably like to get a somewhat higher level information about the resource being currently rendered than having to guess it from the req. Again, something for 0.12 and a more in-depth rendering layer refactoring. (*) http://trac.edgewall.org/attachment/wiki/MacroBazaar/ShowPath.2.py >> This is mainly a matter of convenience and future extensibility. >> We could of course have a `resource_url(resource_id, href)` function >> instead of a `resource.url(href)` method, but I think we will have >> more and more code working at the generic level, and this convenience >> will pay off then (I think it already does). > > You can always layer a convenience layer above a more direct, lower- > level layer. The reverse is not true. > > And in fact, layering a convenience class on top of lower-level > infrastructure improves flexibility, as opposed to reducing it. Well, I have yet to experiment how much pain it is to not have this convenience layer... maybe it's not as much as I expected. >> It is true that /when/ we have the model around, we already have some >> kind of facilities to access the id, but not in an uniform way: >> ticket.id for tickets, page.name for wiki pages. >> And we don't even have a way to get the realm information! > > Well, we don't have now, but I proposed to add simple properties to > the model objects, i.e. Ticket.resource, WikiPage.resource, etc. Ok, that's an approach worth trying. >> We /do/ have some modules that specifically handle /any/ resources: >> those are the timeline and search modules (and more recently the >> attachment module). However they have the advantages of being "core" >> or "well-known" modules, so that it's the responsibility of resource >> managers to implement the interfaces offered by those modules. >> But what if you want to provide as a plugin another module that >> handles >> resources in a generic way? Even if you could write adapters for the >> core/well-known resources, you can't expect to cover all kind of >> resources this way. > > Okay, so we have ITimelineEventProviders, ISearchSources, and all > that, and you're saying you think they're should be something better, No, I'm saying that what works fine for well-known modules will not work (well) for a third-party module. > I guess (correct me if I got you wrong); there shouldn't be a need to > write those "adapters" for resources plugins add to the system. > Plugins should tell Trac what kind of resource they are providing, > and Trac (or yet other plugins) should figure out everything > automagically or something. The something is mainly a generalized change notification system instead of lots of specialized ones, and a bit of metadata about the resources. I don't even have to talk about an eventual Trac cross-reference plugin, I can simply take as an example your spamfilter plugin: first, it has to provide adapters for IWikiManipulator, ITicketManipulator and IAttachmentManipulator, so that it can validate the changes for all of them in an uniform way. Even more, if there's a new kind of resource added to the system, the spam filter can't handle it, unless a new specific adapter is written. As that plugin is not part of the core but nevertheless "well-known" as it's on t.e.o, there's some chance that a 3rd party contributing a resource will provide an adapter for it, but you get the point. I think this is not the best solution, simply because the differences between all those different resources are *very* superficial or even artificial - a more uniform data model or at least a more uniform API would certainly be possible. > I must say that I'd consider that kind of change/vision outside of > the scope of even Trac 1.0. > > But rereading what you're saying, I don't see anything that can be > accomplished with a Resource class, but not with simple tuples and a > component exposing an IResourceManager extension point, as I had > proposed. Again, a convenience could be put in place on top of that, > if it's deemed benefitting. Possibly later. I just think it's much > cleaner to clearly separate the layers here. > > [snip] >> The way forward? >> >> I propose to create a sandbox/context-split branch, where I finalize >> my current version of the changes. Most of the work is already done >> (about 1700 "hunks"), there's no "Context" class left, it works >> reasonably well and there's full coverage for fine grained >> permissions >> on all the modules. > > I'm only +1 on such a branch if it does not include the permission > stuff, as explained above. OK, I'll have a try (and there are only about 300 hunks in the patch, so it's not that big, my mistake). > >> /If/ we decide to go for tuple-based resource identifiers, using that >> branch as a basis will make the work significantly simpler than >> starting >> again from trunk. > > That sounds reasonable. > > [snip] >> I'm just afraid that the situation will repeat itself for 0.12, as >> from >> what I understand, you're probably opposed to some other major design >> proposals of mine, like the generic Trac stuff. This will then lead to >> the question of which approach will the project take, the one I defend >> or the one you defend (which, I admit, I know little about). > > We will need to sort this out *somehow* for the future. Here's what > *I* want: us to release a 1.0 version sometime in this decade, and > postpone any big vision shifts until after that point. > > What I want is to fix the big problems we still have, for example > I18n or documentation/help. I don't yet want to think about multi- > project support, a generic resource system used throughout the code, > or big changes to the plugin/component system. > > There's a life after 1.0, if we even ever reach that point. Well, multi-project support has always been a 1.0 goal, for one. Improved change notification is a topic for 0.12, I think (#1890 and the like). But we'll have other occasions to talk about all this... -- 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 -~----------~----~----~----~------~----~------~--~---
