Hi Stephan, As Steven pointed out (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102412384403844&w=2) we've just started on something similar (so there is some momentum)
in fact what you're talking about here maps to our package 'yer' which offers now some generic interfaces for defining (implementing) and traversing very generic hierarchical repositories... next to 'yer' the 'libre' thing is what allows us to add filtering, ordering and external attributing metadata to the classical filesystem (so the actual libre part in the code is probably only interesting inside the forrest context where we are trying to find a more flexible alternative to the book.xml for documentation stuff, the design around it could fit in with this nicely.) in every case I hope some of my recent experience on building this prototype can be of help, I took te liberty to add some comments inline... > -----Original Message----- > From: Stephan Michels [mailto:[EMAIL PROTECTED]] > > On Fri, 14 Jun 2002, Per Kreipke wrote: > > > > *DirectoryGenerators should be refactored so we have the only > > > DirectoryGenerator with pluggable 'processors' of different > file types. > > > This way, you will be able to generate listings of different files of > > > type in one directory. > > > > That's a great idea but more grandiose. It certainly would be > neat if you > > could (use POI to) extract metadata from MS Office files, etc. I imagine > > there are actually code libraries out there for all kinds of 'file > > introspection' or generating metadata from files. > > > At the moment I'm to evaluating way to get meta informations from > repositories, like slide or over WebDAV. Also I want to be grant this thread adds up the number of sensible examples nicely next to our focus on (1) filesystem with special xmlbased config file in it (libre) there was just one other example: (2) a swing-like treeModel that could be retrieved from a central place (and thus would be available to pure swing clients as well) > permissions and locks to sources. My initial stage was creating > 'SourceDescriptor', which is now in current CVS. But more I think about > it as more I came to the conclusion that I should follow the SoC. > The next idea is create some interfaces for 'Source' similar to > 'WriteableSource' > Haven't thought about it like this, but sure sounds great One of the troubles I was neglecting to solve up to now was how to think about hybrid trees of sources that would have child sources that would come from a different implementation.... If I understand this correctly (young but growing knowledge on cocoon and avalon internals) there would be some kind of knowledge inside Avalon to translate any source-URL into delivering an actual Source implementation? So there could then be a file:///..../dir, a dav://srv/path/collection , and I would nead to think about some libre:///filelike-path/dir?cfg=libre.xml (saying: look at this dir in the libre fasion by reading sort, filter and attributing info from the libre.xml file you'll find there) don't see it working for the images, mp3 case yet (list of file-extension to mimetype to SourceImpl mappings??) In which case each of them could say that one of their kids would in fact exist outside their own implementation focus? (libre.xml could introduce that with the <entry location="dav://..."> ) (Currently I only thought about being able to switch the implementation at the root level,in which case all descendants keep on living in the same implementation space) In every case it would be nice if sourceURL of kids could be returned in a relative manner? > So I have the following proposal: > > BrowsableSource: > > /** if the source a directory */ > boolean isCollection(); > > /** Return the children of the collection */ > Enumeration getChildSources(); > made a type-aware collection instead of the Enumeration (which is one of my (bad?) habbits, it allows me to add some browseEnumeration method that is taking an enumerationVisitor interface implementation class with some acceptItem(theItem) method... this kind of relieves the clients of some of the casting and the boring hasNext() while loop, at the cost of writing an anonymous inner class.) also still in doubth on adding a hasChildSources() next to the isCollection(), the subtle difference being: - isCollection(): can you have kids? - hasChildSources(): do you have any currently? would be a way to get rid of empty <collection /> elms in the generated output. > InformalSource: > > /** To get a meta information from a source */ > SourceProperty getSourceProperty(String namespace, String name); > > /** To set a meta information */ > void setSourceProperty(SourceProperty property); > > /** Get alll informations */ > Enumeration getSourceProperties() > you mean getSourcePropertyNames() with the last one? or do you expect a returned set of namespace-name-value holding objects? (is SourceProperty in alreay existing class maybe?) > RestrictableSource: > > /** Get a permission for a owner */ > SourcePermission getSourcePermission(String owner); > > /** Get a permission for the local owner */ > SourcePermission getSourcePermission(); > > void setSourcePermission(SourcePermission permission); > > Enumeration getSourcePermissions(); > > LockableSource: > > /** Get a lock for a owner */ > SourcePermission getSourceLock(String owner); > > /** Get a lock for the local owner */ > SourceLock getSourceLock(); > > void setSourceLock(SourceLock lock); > > Enumeration getSourceLocks(); > the great thing about SoC is that I don't need to know what this is even about :-) (mapping dav stuff I persume) > The interface InformalSource could be used to get properties > from a source, such like image width and height > > file://test.gif > SourceProperty: namespace http://xml.apache.org/cocoon/source/image > name width > value 480 > > The values should also contain XML fragment like > SourceProperty: namespace http://www.test.org/mymetas > name title > value bla from <a>dgfdh</a> mmm, didn't do this either, in this case you're not thinking about setting the property name-value as an attribute on the <item ns-prefix:name="value"/> elm? but rather as a the content-model for the generated output elm: <item> <ns-prefix:name> <!-- whatever --> </ns-prefix:name> </item> how will you make the destincition between AttributeProperties and NestedElementProperties? In the latter case I'ld also try to avoid returning the property value as a String, but rather hope for a mechanism to let the SourceImpl inject the SAX Events directly to the output, or return at least use a org.w3c.dom.DocumentFragment return type instead. > > The next thing is that cocoon is able to browse through repositories > At the moment DirectoryGenerator is limited to the file:// protocol, I > think. > > I would also come to the point cachable. Source can IHMO implement > recycable, to there is no need to retrieve all meta informations > for every request. > here, here, have been struggling on this one... limited avalon understanding prevents me from seeing full solution though? > I had also took a look Ugo Cei's implementation of CocoBlog. He used RSS > to create a description for every entry in xindice. I doesn't understand > the difference between RSS and RDF. So I used for my first stage RDF. > So my proposal is to write a 'SourceDescriptionGenerator'. It should > work like DirectoyGenerator, catch all informations from a source, and > generate a 'Resource Description'. > > One think, I doen't know to implement is associate 'SourceCredentials' > to the source, such like username and password. > > Perhaps a ExtendedSourceFactory a possibility: > ExtendedSourceFactory: > > Source getSource(SourceCredential credential, String location, Map > parameters) > > So, what do you think, is this the right way? > sorry, can't help you here yet... hope I did in other parts. one more remark, while refactoring the DirectoryGenerator to some TreeOfSourcesGenerator: design should not be thight to a generatorImpl alone: the use case for the transformer version is (avoiding the aggregation) in a lot of cases the output of this thing will be used as some right hand navigation of some webpage, but it can end up generating small sub-trees just about anywhere I guess. In some cases people will think about this more as a concern of the content-editor that would like to write: <navigation-tree src="...." depth=".." /> to be picked up by some TreeOfSourcesTransformer as well. To achieve this I would separate the SAXgeneration stuff in some TreeOfSourceReader to be used by both the traverser, and the generator. > Stephan Michels. > > -marc= --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
