On 5/25/07, Christian Boos <[EMAIL PROTECTED]> wrote:
> OK. On a somewhat related note, I also wanted to follow-up with the
> ResourceDescriptor / RenderingContext split I discussed with you the
> other day on #trac.
>
> The "parent" notion in particular would gain from such a split:
> - some resources have a "parent" resouce if they're not existing
> outside of the scope of that resource and if they need to be deleted
> when the parent resource gets deleted. Typically this is the case for
> attachments. We could imagine having this for comments in the future.
> - the rendering context "parent" is used to represent the nesting of
> rendered content (a wiki fragment of a resource rendered inside another
> wiki resource)
Definitely agree.
> The ResourceDescriptor correspond to the specification of "what" is
> accessed, and the RenderingContext represents "how" the view should be
> rendered (how URLs should be formed, what the expected output mime-type
> is) and finally the req represents the "who" part. The existing wiki
Yep, sounds good to me. One thing not mentioned here is how to obtain the URL
for a resource. We discussed this and mentioned having a "href" method in
the ResourceDescriptor. Something like:
def href(self, req, abs_urls=None): ...
> context can still be used to encapsulate all those aspects
> (ctx.descriptor, ctx.rendering, ctx.req fields).
This I'm not so sold on TBH, as I'm not convinced we need an all-encompassing
"Context" object at all.
> Further refinements of the permission policy could eventually make use
> of the resource descriptors more directly instead of using hash(context).
I agree 100%. The permission system should only be dealing with resources.
These may be resources in the sense that we've been discussing (Wiki pages,
tickets, etc.), or "virtual" resources like "about:config". Regardless, it
doesn't care about the rendering context or request.
PS. The hash(context) is only used for caching policy decisions, so this
wouldn't go away really.
--
Evolution: Taking care of those too stupid to take care of themselves.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
