You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Michael Homeijer <M....@devote.nl> on 2002/02/12 12:08:53 UTC
RE: xmldb logicsheet (XMLDBTransformer is a great start)
Have a look at the XMLDBtransformer in scratchpad, it could be easier to add
your functionality there.
Additional functionality for the XMLDBTransformer could be:
- resolving nested xml queries and/or structures (ie. get the collection and
then get a document)
- adding stuff dbxml provides at the command line, ie. listing, adding,
removing and querying collections
To do this two changes have to be made to the transformer:
1. implementing it in a way that commands can easily be added to it. (How
about innerclasses that handle a command?)
2. you should be able to use results from a query or a command in the next
query.
HTH,
Michael Homeijer
> -----Original Message-----
> From: Martin Holz [mailto:holz@fiz-chemie.de]
> Sent: dinsdag 12 februari 2002 12:05
> To: cocoon-users@xml.apache.org
> Subject: Re: xmldb logicsheet ?
>
>
> Hi,
>
> Gianugo Rabellino wrote:
>
> > Guys,
> >
> > please *don't* use the XMLDB generators. They are going to
> be deprecated
> > RSN, since they are replaced by the much more powerful Source
> > abstraction that allows to use plain XMLDB URIs to retrieve
> documents
> > and, yes :), XPath-query the collections :)
> >
> > Usage is straightforward: put the correct DB configuration in
> > cocoon.xconf and use xmldb:// URLs wherever you want in the
> sitemap :)
> >
> > If you are willing to do XPath queries all you need is to use an
> > xpointerish syntax such as:
> >
> > xmldb:xindice://my.host.name/my/collection/#//my/xpath[@query]
> >
> > Please also note that for the brave ones there is also an
> ongoing XMLDB
> > transformer worth noticing in scratchpad.
> >
> > HTH,
>
> I see one problem with the source concept, if you are
> retrieveing lots of
> resources from the same collection. There are three steps to
> get a resource from xindice;
>
> 1) register database
> 2) get collection
> 3) get document
>
> Typical performance numbers are:
> 1) Need 158.0 ms for Database.
> 2) Need 1962.0 ms for Collection.
> 3) Need 294.0 ms for Document.
>
> Time for 1) drops dramatically after the first call.
> Time for 3) is unavoidable. Time for creating a collection
> drops too, if you
> call it more than once, but is still high. So you want to
> keep the collection
> open, if you need to get documents from this collection often.
>
> You could configure a generator to cache a collection.
> That does not work with current implementation, but it would
> be straight
> forward to add. I can't see, how to add this capability to
> the source URL.
>
>
> Regards
> Martin
>
> --
> Martin Holz <ho...@fiz-chemie.de> phone: 0049-30-39977 218
> FIZ CHEMIE BERLIN
>
>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: xmldb logicsheet (XMLDBTransformer is a great start)
Posted by Martin Holz <ho...@fiz-chemie.de>.
Hi,
Michael Homeijer wrote:
> Have a look at the XMLDBtransformer in scratchpad, it could be easier to
> add your functionality there.
I agree.
> Additional functionality for the XMLDBTransformer could be:
> - resolving nested xml queries and/or structures (ie. get the collection
> and then get a document)
> - adding stuff dbxml provides at the command line, ie. listing, adding,
> removing and querying collections
>
> To do this two changes have to be made to the transformer:
> 1. implementing it in a way that commands can easily be added to it. (How
> about innerclasses that handle a command?)
> 2. you should be able to use results from a query or a command in the next
> query.
The standard way in Cocoon to do this, is chaining of Transformers. This
requires, that you know at deploy time, how deep your queries are nested.
However you should write a purpose build generator/transformer anyway, if
your queries are very complicated and nested .
Martin Holz wrote:
> > I see one problem with the source concept, if you are
> > retrieveing lots of
> > resources from the same collection. There are three steps to
> > get a resource from xindice;
> >
> > 1) register database
> > 2) get collection
> > 3) get document
> >
> > Typical performance numbers are:
> > 1) Need 158.0 ms for Database.
> > 2) Need 1962.0 ms for Collection.
> > 3) Need 294.0 ms for Document.
> >
> > Time for 1) drops dramatically after the first call.
> > Time for 3) is unavoidable. Time for creating a collection
> > drops too, if you
> > call it more than once, but is still high. So you want to
> > keep the collection
> > open, if you need to get documents from this collection often.
> >
> > You could configure a generator to cache a collection.
> > That does not work with current implementation, but it would
> > be straight
> > forward to add. I can't see, how to add this capability to
> > the source URL.
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>