Paul,
Please wait until tomorrow to make this change so as to not disrupt the
plugfest.
Thanks
Paul Sandoz wrote:
> 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.
>>
>
--
- Doug