Am 27.09.2007 um 19:43 schrieb Christian Boos:
> Hm, it looks like your answer didn't cover the updated proposal of
> this morning:
>
> http://trac.edgewall.org/wiki/TracDev/
> ContextRefactoring#TheResourceclassforresourceidentification
To quote:
"As fine-grained security and permission checks are becoming the
rule in Trac, one shouldn't be able to access a resource without the
appropriate credentials."
I *strongly* disagree with this. That *may* be something to think
about for a future release, but most definitely not for 0.11.
And the whole concept of "resources have to be created through the
permission system" is wrong IMO. But that's not the point. The point
is that we should not be thinking about doing anything like that for
0.11. Both Alec and myself have stated early on that we think this
was out of scope for the release.
My idea (and I think I'm not alone here) was that we should go back
and fix Context by removing/simplifying. What you're proposing here
seems to go in a totally different direction.
> On Sep 27, 7:15 pm, Christopher Lenz <[EMAIL PROTECTED]> wrote:
>> 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).
What I meant was that I've seen examples of stuff that wouldn't ever
be an actual resource identifier. I may have gotten the wrong
impression here, or may be misremembering the examples
Anyway, I strongly doubt we'll need to identify the "resource/
context" in which some other resource is being rendered. The only use
case I can think of are relative links (as in ../foo instead of /bar/
foo), and those are more trouble than they're worth. That's not to
say that the idea of a "rendering context" isn't needed, just that
that context doesn't need to know about the (pseudo-)resource in
which it's being used.
>> 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.
Well, elsewhere in my mail I said that there should be ways to get
display_name etc without going through a DB lookup. Just adding a
get_resource_info() method (or similar) to the IResourceManager
interface I proposed would do the trick, while still not requiring
the use of resource "descriptors" as opposed to simple identifiers.
[snipped lots]
Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
