cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes" <Un...@hippo.nl>
Subject RE: InspectableSource
Date Mon, 27 Oct 2003 15:49:16 GMT

In order to add the possibility to remove properties from sources to
SourcePropsWritingTransformer I'd like to slightly change the syntax.

Currently you can write:

<source:patch xmlns:source="http://apache.org/cocoon/propwrite/1.0">
 
<source:source>repository:context://samples/repository/sitemap.xmap</sou
rce:source>
   <source:props>
     <myns:author xmlns:myns="meta">me</myns:author>
   </source:props>
</source:patch>

I'd like to instead replace the source:props with source:set and
source:remove so that we can write:

<source:patch xmlns:source="http://apache.org/cocoon/propwrite/1.0">
   <source:source>repository:context://sitemap.xmap</source:source>
   <source:set>
     <myns:keyword xmlns:myns="meta">mystuff</myns:keyword>
   </source:set>
   <source:remove>
     <myns:author xmlns:myns="meta" />
   </source:remove>
</source:patch>

This is similar to the PROPPATCH syntax.

Anybody against this? Guido, is this OK with you?

-- Unico

> 
> -----Original Message-----
> From: Unico Hommes 
> Sent: maandag 27 oktober 2003 14:52
> To: dev@cocoon.apache.org
> 
> 
> I am looking into extending SourcePropsWritingTransformer to 
> also be able to remove SourceProperties. One thing I need to 
> decide is how to access SourceProperties now that we have 
> SourceDescriptor interface.
> From SourceDescriptionGenerator I can see that the 
> distinction between SourceInspector and InspectableSource was 
> mainly that of computed vs.
> modifiable. With the new SourceDescriptor interface this 
> distinction does not exist anymore and so we have in fact two 
> interfaces with the same functiality. We need to decide what 
> to do with that.
> 
> I see three possibilities:
> 
> 1) keep InspectableSource interface. SourceProperty related 
> sitemap components talk with both interfaces to do their job, 
> favoring InspectableSource if the Source implements it else 
> falling back on SourceDescriptor.
> 
> Pro: - SourceProperty related coding can be done directly 
> onto the Source.
> Con: - Confusing what properties are managed where
>      - Clients have two interfaces to choose from
> 
> 2) deprecate InspectableSource in favor of SourceDescriptor 
> and migrate SourceProperty related sitemap components to use 
> the SourceDescriptor interface instead, taking care for 
> backwards compatibility with Sources that haven't moved away 
> from SourceInspector yet.
> 
> Pro: - Client need to use only one interface
> Con: - Need to refactor some things
>      - SourceProperties are not directly available on Source.
> 
> 3) make SoureProperty related sitemap components talk 
> directly to InspectableSources only. Create a Source delegate 
> - callit RepositorySource - that adds inspectability to 
> arbitrary sources by talking to SourceDescriptors.
> 
> Pro: - One interface
>      - SourceProperties directly visible on Source
> 
> Ok, I think I just answered my own question ;-D, but I'd be 
> interested in others' opinions.
> 
> What do others think?
> 
> -- Unico
> 
> 

Mime
View raw message