Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Date: Fri, 21 Jun 2002 15:54:24 +0200 (CEST)
From: Stephan Michels <stephan@apache.org>
To: cocoon-dev <cocoon-dev@xml.apache.org>
Subject: RE: [PROPOSAL] Sources,
 the next generation RE: Speedup *DirectoryGenerator
In-Reply-To: <LOEAIGHAMOLFGJLAJOFPMEOCDAAA.mpo@outerthought.org>
Message-ID: <Pine.LNX.4.33.0206211542060.27354-100000@vern.chem.tu-berlin.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Fri, 21 Jun 2002, Marc Portier wrote:

>
> > Hi,
> >
> > I have a question, which implementation do you like more?
> >
> > BrowseableSource:
> >
> >   SourceList getChildSources()
> >
> > SourceList:
> >
> >   Source getSource(int index)
> >   int    getSourceCount();
> >
> > or
> >
> > BrowseableSource:
> >
> >   Source getChildSource(int index)
> >   int    getChildSourceCount();
> >
>
> I don't see this second as being worse in fact, it feels quite natural. I
> would take this one.
> As stated earlier I do like the
>
>     void browseChildSources(ChildSourceBrowser csb);
>
> approach together with the
> 	interface ChildSourceBrowser {
> 		void visit(Source s);
> 	}
>
> to run through lists, it actually relieves
>
> > perhaps it is better to get all sources over the SourceFactory.
> >
> > BrowseableSource:
> >
> >   String getChildSource(int index)
> >   int    getChildSourceCount();
> >
>
> Was thinking on this one myself...
> Haven't looked into the SourceFactory yet, but I guess it's main thing is to
> resolve a URL to a Source, right?

Right, so the last choise ;-) One problem, which occurs, is the pseudo
protocol. A libre source should return getSystemId()='libre://.....'
But WebDAV source return getSystemId()='http://...' instead of 'dav://...'
And what should return getChildSource(..)?

> While I like the clean SoC that is in there, this _is_ quite a distinct and
> isolated action, in some implementations (like libre) that would allow for
> less possibilities of caching, property inheritence and the like:
>
> Indeed the two options are also to my guess:
> When the Source Traverser (the generator/transformer) asks
> getchildSource(s)()
> (or when using the browsing interface/visitor)
>
> (1) OR he gets URLS to children of that Source
> 	in this case the URL needs to provide all knowledge to correctly build up
> the pointed at Source object through the Factory
>
> (2) OR he gets directly the factored Source type children of that Source
> 	in this case the ParentSource has a bit more control.  It still needs to
> provide a URL to the ChildSource so the factory can build it, but if that
> child is from the same Family of Sources this parent can maybe call upon
> some extra method it knows on that type of source to past down (1) some
> knowledge that has already bean calculated and/or  (2) some configuration
> settings that need to be inherited by the child sources.
>
> Purely theoretically and in general terms I don't really see a faulty design
> in having a FactoredProduct know about it's own factoy and using that to
> produce other FactoredProducts that are composites of it's own being.
>
> And pragmatically, one of the big goals of libre is to relieve the need of
> having a book.xml in all directories of the documentation system... so I
> really need this notion of some dad that just parsed it's own libre.xml to
> pass it through to it's kid.  (And the URL will simply not be expressive
> enough to pass all details)
>
> Other way of working is of course that there is an overloaded method on the
> SourceFactory that produces the Source based on 2 arguments: not only the
> URL (that even could be relative then) but also the ParentSource object
> (maybe that method is alreay in the cocoon code, damn I really need to take
> some time to look into that stuff.)

I think it should work like this:

Source source = resolver.resolveURI("dav://mydir/mydir2/");
if (source instanceof TraversableSource) {
    TraversableSource tsource = (TraversableSource) source;

    Source parent = resolver.resolveURI(tsource.getParentSource());
    Source child = resolver.resolveURI(tsource.getChildSource(0));
}

> >
> > Sounds the name BrowseableSource good to you, or should we name the class
> > TraversableSource?
> >
> >
>
> 'browsing' lacks the meaning of hierarchy I persume, 'traversing' does a
> better job there
> other alternative would be 'composable'
>  - which maybe relates to the Avalon thing in more ways then we'ld like

That the reason why I used the prefix Source... for every class.

>  - and also puts in some existence dependence that often is not there (a
> file is not really a composite of a directory, it's just one of the elements
> that happens to sit in it currently)
>
> remaining current idea I have is 'hierachical' or is this to easy?

I think TraversableSource sounds best ;-)


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org