cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bart Molenkamp" <>
Subject RE: AbstractResourceReader?
Date Tue, 22 Mar 2005 15:43:45 GMT

First, sorry for my late reply, and for my horrible planning (adding
this just before a release ;-).

I've created the StreamReader (discussed here [1]). I've copied the
ResourceReader, and made modifications where required: where the
ResourceReader uses a source, I use (configurable) JXPath expressions to
look up the information required:
* the input stream
* the mime type
* the content length.

The implementation can be found here [2].

The rest of the code is copied from the ResourceReader implementation,
and could thus be shared in an abstract class. For example, an
AbstractResourceReader class which has three methods:
getMimeType() -> already required by a Reader, right?

The current resource reader can implement these methods with the source
it looks up. The StreamReader can implement these methods and return
values found by Xpath expressions.

I can make the change, if it is a good idea of course (other ideas are
also welcome). Please let me know what others think.


> -----Original Message-----
> From: Alfred Nathaniel []
> Sent: Wednesday, March 02, 2005 5:30 PM
> To:
> Subject: Re: AbstractResourceReader?
> On Wed, 2005-03-02 at 15:38, Bart Molenkamp wrote:
> > Hi,
> >
> > A while ago I was discussing how to build a reader that could get
> > input stream from the context object using JXPath. It gets the
> > information from the context object using configurable Xpath
> > expressions:
> > - the content stream
> > - the mime type
> > - the content length
> >
> > I've created the reader by simply copying the existing
> > and replaced all the code where a Source was used to use the content
> > input stream, the content length and the content type that are
passed in
> > the context object.
> >
> > The reader is working this way, but I was wondering if it makes
sense to
> > create another abstract reader that handles things that are common
> > the ReasourceReader and the StreamReader (the reader I've created).
> > concers many HTTP specific code such as byte range, content
> > etc. I've used all that code (only difference is that my reader
> > cacheable, don't know how to generate a key yet).
> >
> > Can someone tell me what code would be common (as I don't have
> > knowledge about these http byte range, expiration etc things), or if
> > doesn't make sense at all.
> >
> > Bart.
> I think it would be more elegant to wrap your input stream in a Source
> object (StreamSource extends
> Then your StreamReader can extend ResourceReader and just needs to
> override the setup method.
> However, ResourceReader.setup must be refactored to move the
> resolving into a separate method which a derived class can override.
> Otherwise StreamReader.setup cannot call super.setup.  This is
> not only to avoid duplicating the parameter decoding in
> ResourceReader.setup but also because you would need to call
> super.super.setup which is not allowed in Java.
> Cheers, Alfred.

View raw message