You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2001/11/14 11:34:40 UTC
Discussing New Interfaces
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.
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.
c) XMLizable and XMLFragment
These marker interfaces are used to convert an arbitrary object
to an DOM node or to send XML events.
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.
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.
So, let's start discussing this. I'm really interested in your opinion,
even if have to start over from scratch....(just a joke)
Cheers
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Discussing New Interfaces
Posted by Peter Donald <do...@apache.org>.
On Thu, 15 Nov 2001 02:25, Berin Loritsch wrote:
> > 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.
I don't think XMLizable should be in framework - it has nothing to do with a
generic component model or lifecycle management and isn't as useful as the
ExceptionUtil/Version classes.
XMLizable is something that could be used to implement COnfiguration
instance. If so then the COnfiguration implementation should be in excalibur
rather than framework IMHO.
--
Cheers,
Pete
---------------------------------------------------
"If you don't know where you want to go, we'll make
sure you get taken."
Microsoft ad slogan, translated into Japanese.
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Discussing New Interfaces
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Discussing New Interfaces
Posted by Berin Loritsch <bl...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>