cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Michels <step...@vern.chem.tu-berlin.de>
Subject RE: [PROPOSAL] Sources, the next generation RE: Speedup *DirectoryGenerator
Date Mon, 17 Jun 2002 09:33:00 GMT


On Sat, 15 Jun 2002, Marc Portier wrote:

> 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...

One thing a want to prevent is, to get a one more 'DirectoryGenerator' or
in your case a TreNavigationGenerator.

So my idea was to have one generator and several implementations of
SourceFactories. It makes also the life easier to get the access over
different component.


> > -----Original Message-----
> > From: Stephan Michels [mailto:stephan@vern.chem.tu-berlin.de]
> >
> > 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?

Yes, that is the way how it works.

> 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??)

There should be some kind of SourcePeropertyHelper, to get standard
informations of different sources. Perhaps something like that

<source-properties>
 <source-property extension="jpg"
class="org.apache.cocoon.components.source.helper.ImageProperties"/>
 <source-property extension="mp3"
class="org.apache.cocoon.components.source.helper.MP3Properties"/>
</source-properties>

> 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.)

Yes, of cause, ther can be some kind of SourceList, SourcePropertyList.

> 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.

Yes, a method hasChildSources is, I think, better.

> > 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?

The last one ;-)

> (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?

I don't. I want a similar syntax to PROPPATCH

http://asg.web.cmu.edu/rfc/rfc2518.html#sec-8.1.1

> 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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


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


Mime
View raw message