avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: Discussing New Interfaces
Date Wed, 14 Nov 2001 15:49:03 GMT

Berin Loritsch wrote:
>
> Carsten Ziegeler wrote:
>
> > Hi,
> >
> > I just started moving some components from Cocoon over to Excalibur.
> > Rather than moving all at once, I would like to discuss the some
> > moved components and then add some more as the current interfaces
> > might have influence on the following components.
> >
> > So, I added all the stuff to the xml and the source package of
> > scratchpad in excalibur.
> >
> > a) XMLConsumer, AbstractXMLConsumer, ContentHandlerWrapper
> >    The XMLConsumer simply unifies LexicalHandler and ContentHandler.
> >    The AbstractXMLConsumer is an abstract implementation of this
> >    interface, simply doing nothing. And the ContentHandlerWrapper
> >    implements the XMLConsumer to wrap a ContentHandler or
> >    a ContentHandler and a LexicalHandler to an XMLConsumer.
> >    I think these components do not need discussion.
>
>
> They are pretty straight forward.
>
>
> > b) Parser, XercesParser, JaxpParser
> >    The Parser interface defines an XML Parser which can either send
> >    SAX events or create a DOM Document. XercesParser and JaxpParser
> >    are two implementations.
> >    I changed the Parser interface from the Cocoon version in order
> >    to make the implementation ThreadSafe - if possible. This change
> >    was already discussed on the Cocoon mailing list.
>
>
> There could be two policies:
>
> 1) new parser every time.
> 2) reuse parser until it emits an exception.
>
> Of course, this means that you will have a new wrapper class to intercept
> the exceptions--or perhaps an ErrorHandler for each parser registered with
> the component.
>
I think this is done already in the PooledJaxpParser of the 2.1 Cocoon
branch.
We could use that. Yes.

>
> > c) XMLizable and XMLFragment
> >    These marker interfaces are used to convert an arbitrary object
> >    to an DOM node or to send XML events.
>
>
> They are useful in application programming--and possibly our serialization
> framework for Components.
>
> If this is the case, these interfaces (or at least the XMLizable
> one) would
> live in Framework so that Configuration can extend it.
>
>
> > d) Source, SourceHandler, SourceFactory
> >    Now this is more or less the source resolving component from Cocoon.
> >    The Source interface describes any source which is resolved by the
> >    SourceHandler. The SourceFactory describes pluggable protocols
> >    which can be used by the SourceHandler to resolve the systemIds.
> >    The other files in this package are implementation.
> >
> >    We should discuss if you are all happy with those three interfaces.
> >    The usual process is to get the SourceHandler and get using this
> >    handler a Source object for a systemID. This Source object can
> >    then be asked for an InputStream, an InputSource or if it is
> >    XMLizable or XMLFragment for it's XML representation etc.
> >
> >    These interfaces have been proved in Cocoon, but perhaps they can
> >    still be enhanced.
>
>
> Is there any way we can merge the Source and Resource classes?  That
> way, we can seemlessly take advantage of the Monitor package.
>
>
> > In addition we need a link to the monitor package. The simplest solution
> > might be to define a SourceResource in the monitor package
> which monitors
> > a Source object.
>
>
> Perhaps the Source object can extend the Resource or
> StreamResource objects?
>
>
> > So, let's start discussing this. I'm really interested in your opinion,
> > even if have to start over from scratch....(just a joke)
>
>
> What would be the barrier to using the Resource object directly?
>
I'm really not sure about this. The Resource class adds many
methods/features
which you usually not need for source resolving. OK, you can say, who cares
and perhaps you are right. But extending the Resource (or StreamResource)
requires
to implement all methods for every case.
Without the ability to say why, I feel that we should keep those two
issues separate. It seems a little bit cleaner.
If you use the SourceResolver you get a Source object. If you want to
monitor
it, you simpley create a SourceResource (nice name anyway) and can monitor
it.

One problem might be the Constructor for the Resource object which is simply
a String. The Source implementations often need more, e.g. the URLSource
gets this
String, an optional SourceParameters object and it needs a ComponentManager
to be able to fulfill the toSAX() method. And custom protocols might need
others.

So, you see, these are only small arguments against it.

Carsten
>
>
> --
>
> "Those who would trade liberty for
>   temporary security deserve neither"
>                  - Benjamin Franklin
>
>
> --
> To unsubscribe, e-mail:
<mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message