Unico Hommes <[EMAIL PROTECTED]> wrote:
> 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.
Ah, I see.
> 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:#*","http://apache.org/cocoon/doco/1.0#authors"}). 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).
I don't think it should be an error. Allowing ambiguities in the mapping
would be a way we both get the behaviour we envision (see below).
>
> 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 accordingly.
Yes, we are dealing with 2 concepts.
1) statically defining which SourceInspector deals with which properties
(based on namespaces and/or property names).
2) each SourceInspector dynamically determines at runtime which
properties it deals with. How that is determined is a concern of the
individual SourceInspector implementation (may that be namespaces,
property names or something completely different like simply trying to
get the property). This would even allow for implementations where at
runtime the same property may be dealt with by different
SourceInspectors at different times depending on some runtime
circumstances (maybe that's FS, I don't know).
Now I think it's possible to get both behaviours.
The way 2) currently is implemented is that each
SourceInspector.getSourceProperty() in turn is called until one returns
not null.
Now this behaviour can still be available with the mechanisms you
proposed. One would just implement all the SourceInspector's
getHandledPropertyTypes() to return "*#*" and then again each
getSourceProperty() in turn gets called. Wether an additional
handlesProperty() method is needed, I don't know.
One could still get the performance improvements you have in mind by
having priorities based on explicitness or by having mutual eclusive
values returned by getHandledPropertyTypes().
The only change to your proposal to allow for both behaviours would be
to not prohibit ambiguities.
Deal? :-)
>
> 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:
> http://apache.org/cocoon/inspector/image/1.0 .
Exactly. An example where dynamic behaviour would be beneficial.
Guido
>
> 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
