Hi Kohsuke,
I just updated XMLStreamBuffer to include your good ideas (the creating
of a mark from a Creator still needs to be implemented, i will do that
soon). All concrete buffer implementations extend ImmutableStreamBuffer
and the process method operate on instances of ImmutableStreamBuffer.
Most things depending on stream buffer should not change, with one
exception. I removed the cruft from the helper methods on
ImmutableStreamBuffer to process a buffer using StAX and SAX, it is all
consistent in terms of readFrom and writeTo.
I can modify the JAX-WS code as required for the lastest streambuffer
jar, i presume this OK or should i wait?
Paul.
Kohsuke Kawaguchi wrote:
>
> I think some ofthe XMLStreamBuffer method names can be named better, and
> this is the proposal to change it.
>
> For example,
>
> StreamReaderBufferProcessor processUsingStreamReaderBufferProcessor();
> XMLStreamReader processUsingXMLStreamReader();
>
> should be:
>
> StreamReaderBufferProcessor newXMLStreamReader();
>
> (we don't need two methods that does the same -- it just clutters the
> signature. "processUsing" isn't very obvious what it does. "new" or
> "create" is terse and suffice.)
>
>
>
> void processUsingSAXContentHandler(ContentHandler handler);
>
> should be:
>
> void writeTo(ContentHandler handler);
>
> (once again "processUsing" doesn't make a lot of sense to me)
>
>
> There are a few others like this. If it's OK with Paul, I'd like to make
> these changes.
>
>
> The other usability issue is how to create a mark. This isn't very
> intuitive today, as you are expected to call the constructor by
> yourself. I think it's better if I can do it bit more nicely, like:
>
> StreamWriterBufferCreator swbf = xsb.createFromXMLStreamWriter();
> // write something into swbf
> XMLStreamBuffer mark = swbf.mark();
>
> It's also strange that XMLStreamBufferMark derives from XMLStreamBuffer,
> when XMLStreamBufferMark offers less functionality than XMLStreamBuffer
> (for example XMLStreamBufferMark is read-only.)
>
> This should be the other way around. XMLStreamBufferMark should be an
> interface that only defines methods like "newXMLStreamReader", and
> XMLStreamBuffer should implement it (and add methods for filling data
> in.) The user appliations shouldn't need to call the constructor of
> XMLStreamBufferMark (instead related objects should define a method like
> "mark" that returns a mark), so it should be suffice for it to be an
> interface. This makes it harder to misuse XMLStreamBuffer, and it also
> makes the developer surface smaller without reducing functionality.
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109