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