cocoon-dev mailing list archives

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

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:
getInputStream()
getContentLength()
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.

Thanks,
Bart.

[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110872385503566&w=2
[2]
http://issues.apache.org/bugzilla/attachment.cgi?id=14534&action=edit
> -----Original Message-----
> From: Alfred Nathaniel [mailto:a.nathaniel@bluewin.ch]
> Sent: Wednesday, March 02, 2005 5:30 PM
> To: dev@cocoon.apache.org
> 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
it's
> > input stream from the context object using JXPath. It gets the
following
> > 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
ResourceReader
> > 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
to
> > the ReasourceReader and the StreamReader (the reader I've created).
It
> > concers many HTTP specific code such as byte range, content
expiration,
> > etc. I've used all that code (only difference is that my reader
isn't
> > cacheable, don't know how to generate a key yet).
> >
> > Can someone tell me what code would be common (as I don't have
specific
> > knowledge about these http byte range, expiration etc things), or if
it
> > 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
o.a.excalibur.source.impl.AbstractSource).
> Then your StreamReader can extend ResourceReader and just needs to
> override the setup method.
> 
> However, ResourceReader.setup must be refactored to move the
inputSource
> resolving into a separate method which a derived class can override.
> Otherwise StreamReader.setup cannot call super.setup.  This is
necessary
> 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.


Mime
View raw message