avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Discussing New Interfaces
Date Wed, 14 Nov 2001 15:25:06 GMT
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.

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


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

View raw message