cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes" <>
Subject RE: repository block (was Re: [RT] Source extensions)
Date Fri, 24 Oct 2003 15:42:23 GMT

Guido Casper wrote:
> Unico Hommes <> wrote:
> > Guido Casper wrote:
> >> 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.
> >>
> >
> > Aha, now I get the acl example.
> >
> >> In addition the rules might be more complex than this. I.e.
> >> permission to access all properties except one particular 
> namespace.
> >>
> >
> > OK, but in the case of acl, shouldn't that be handled 
> somewhere else 
> > than on the level of the individual inspector? This is 
> something that 
> > is better handled at the level of the manager.
> Yes, maybe, if _you_ are the one implementing ACLs.
> But taking the webdav sample again, you may be just accessing 
> a remote webdav repository which has ACLs defined on it.

OK, I think the confusion is due to the method name which may be
misleading in this case: getExposedPropertyTypes(). A better name would
be getHandledPropertyTypes() or "boolean handlesProperty(String ns,
String name). It's meaning is confined to communicating the types of
properties the inspector deals with. Not whether it can actually return
the property within the current runtime context. That type of processing
will be dealt with inside getProperty/setProperty methods because it
doesn't influence the inspector selection process.

In the WebDAV example above, the WebDAVSourceInspector statically
defines what property types it deals with (for instance
{"DAV:#*",""}). At runtime when
the manager is queried for a such a property the method is forwarded
only to the WebDAVSourceInspector. That way, if the current user is not
allowed to change the authors property the current source, the method is
not forwarded to a inspector that handles *#* types because the
WebDAVSourceInspector asserted it didn't handle this property type
because the user isn't allowed to.

In fact, revisiting our earlier discussion of caching of
inspector->propertytype mappings, I think that this shows that this
caching actually *can* and *should* be done by the manager during
initialization. I say *should* because we need a way to catch
ambiguities in the mapping (defining two inspectors that explicitly
handle the same property type is an error).

What if we define both stages:

During initialization the manager queries the inspectors for the
property types they each wish to handle by calling
getHandledPropertyTypes(). Inspectors handling arbitrary property types
can specify so using the wildcard syntax mentioned earlier.

At runtime, during property handling, the manager looks for inspectors
that handle the queried property. If it finds an exact match it calls
"boolean handlesProperty(Source source, String ns, String name)" to
verify runtime specifics. Only if that method returns true does the
manager forward the method call to that inspector. Else if no specific
match was found but an inspector exists that handles arbitrary property
types the handlesProperty(..) method is called on that more general
inspector and the original method is forwarded to that one instead

This would handle for example the situation we currently have with the
GIF- and JPEGSourceInspectors that actually deal with the same type of
properties but define separate namespaces for them respectively. I'd
like to instead use the same property namespace for these: .

Their handlesProperty() method would be implemented as something like:

// JPEGSourceInspector:
boolean handlesProperty(Source source, String ns, String name) {
  if (ns.equals(NS) && (name.equals(WIDTH) || name.equals(HEIGHT)) {
    return (source.getURI().endsWith(".jpeg"));
  return false;

-- Unico

View raw message