[Biojava-l] Re: unexpected behavior in StAX, StringElementHandlerBase

Christopher Pickslay chrispix@bigfoot.com
Tue, 18 Sep 2001 10:39:14 -0700


All of the StAXContentHandlerBase implementations appear to share this 
problem. They each contain a StringBuffer field that is initialized along 
with the class, rather than in startElement(). So not only will they cause 
this behavior with sequential elements, but it means a 
StAXContentHandlerBase instance cannot be re-used. I'd recommend 
initializing the StringBuffer in startElement(), as that would be the 
expected behavior.

As to how to treat child elements, I'd recommend having 
StringElementHandlerBase throw an exception (as it currently does). But it 
would be a good idea to add a MixedElementHandlerBase class which allows 
for the retrieval of character data and allows the implementor to handle 
delegation for child elements.


>Date: Tue, 18 Sep 2001 16:14:39 +0100
>From: Thomas Down <td2@sanger.ac.uk>
>To: "Michael L. Heuer" <heuermh@acm.org>
>Cc: biojava-l@biojava.org
>Subject: Re: [Biojava-l] unexpected behavior in StAX, StringElementHandlerBase
>Organization: This tangled web on which I'm laid intwined
>
>On Tue, Sep 18, 2001 at 10:50:13AM -0400, Michael L. Heuer wrote:
> >
> > All,
> >
> > Perhaps I'm making an incorrect assumption, but shouldn't a String
> > element handler return the string value of just the current element?  I'm
> > seeing a concatenation of all the values:
> >
> >  [java] There was 1 failure:
> >  [java] 1) testStringElementHandlerBase(ConfusedStAXHandlerTest) 
> "expected:<d> but was:<abcd>"
>
>
>Okay, you've got a good point here.  I'm not really used
>to XML with mixed content models (other than HTML, obviously...),
>but I think you're probably right in saying that StringElementHandlerBase
>should just return the immediate child string.  What I'm not
>so clear about is whether it should tolerate (and silently ignore)
>child elements, or whether it should fail when it encounters
>a startElement.  I'm actually inclined to think the latter, but
>I'm quite open to suggestions on this.
>
>    Thomas.
>
>
>--__--__--
>
>_______________________________________________
>Biojava-l mailing list  -  Biojava-l@biojava.org
>http://biojava.org/mailman/listinfo/biojava-l
>
>
>End of Biojava-l Digest