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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
