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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
