cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guido Casper" <gcas...@s-und-n.de>
Subject Re: repository block (was Re: [RT] Source extensions)
Date Fri, 24 Oct 2003 12:20:55 GMT
Unico Hommes <Unico@hippo.nl> wrote:
>> The way the manager caches the values for lookups looks to me
>> like sacrifying a lot of flexibility.
>
> Well, I would say not a *lot* but a *little*. But perhaps we could
> make it better.^

OK :-)

>
>> I don't really see a
>> way to avoid the looping (Is it really that costly?).
>>
>
> Yes, it can be. This is the one of the reasons WebDAV specifies a way
> to PROPFIND specific properties. Consider a PROPFIND call on a
> collection with depth 1. The collection contains 20 children. The
> propfind queries for the  property "myns:myprop". The following
> inspectors are registered with the manager: simple jdbc inspector,
> webdav inspector, xpath inspector.
>
> In the case that you are looping over the inspectors you could find
> yourself in a situation where it takes 20 database calls + 20 webdav
> calls + 20 xpath traversals just to find out that the property doesn't
> exist on the children of the collection.

Yes, I see.
I didn't meant to say getExposedPropertyTypes() is not useful. It's just
how it is implemented and optimized is a concern of the individual
SourceInspectors and each of them should be asked each time. And I'm
fine with the change you proposed below.

>
>> Caching the set of supported properties is ok, but it should
>> be a concern of the individual SourceInspector implementation
>> IMO, since it could change at runtime (think access control
>> for instance). That might also be a reason for the above
>> lookup mechanism to break.
>>
>
> Why couldn't this use case be implemented by declaring an inspector
> that handles aclns#* properties?

No, I don't mean properties describing the access permissions but rather
the properties affected by access permissions. You might be allowed to
access a particular property on one source but not on another.

In addition the rules might be more complex than this. I.e. permission
to access all properties except one particular namespace.

>
> Anyway, I see your point of caching the set of supported properties
> with the individual SourceInspectors and I see why that would solve
> changes at runtime. I hadn't thought about that case yet. I'd be +1
> for changing it that way.

OK.

>
> B.t.w. I noticed you hadn't moved SourcePropsWritingTransformer in
> webdav block to repository yet. Any particular reason why? Should I
> move it?

I'm not sure whether the repository block is the place most suited, but
it seems more suited than the webdav block. So, please, go ahead. And
use the chance to rename it to this name (instead of
SourcepropsWritingTransformer with lower "p" :-)

Guido


Mime
View raw message