how do you think about about an adapter in the Un~/marshallerHandler layer
like this:
class UnmarshalHandlerAdapter{
public UnmarshalHandlerAdapter(XMLStreamReader staxStreamReader,
UnmarshalHandler unmarshalHandler){
...
}
public void adapt(){
int depth = 0;
int event = staxStreamReader.getEventType();
if (event == XMLStreamConstants.START_DOCUMENT) {
while (!staxStreamReader.isStartElement()) event =
staxStreamReader.next();
}
unmarshalHandler.startDocument();
...
do ({
switch (event) {
case XMLStreamConstants.START_ELEMENT:
depth++;
...
unmarshalHandler.startElement (uri, localName,
qName, atts);
break;
case XMLStreamConstants.END_ELEMENT:
...
unmarshalHandler.endElement (uri, localName, qName);
depth--;
break;
case XMLStreamConstants.CHARACTERS:
unmarshalHandler.characters();
break;
...
...
default:
...
}
event = staxStreamReader.next();
} while (depth != 0);
unmarshalHandler.endDocument();
}
}
2008/4/3, Werner Guttmann <[EMAIL PROTECTED]>:
>
> Hi Jiantan,
>
> looking at your ideas, I wonder whether this approach is a good one
> (though it is a valid one). Let me try to express my thoughts (slightly
> unstructured):
>
> - Is is really a good idea to expose the technologies we are using
> internally to parse an XML document to the user. In other words, should the
> user know and explicitely have to use classes that carry names that are
> linked to a technology such as SAX or STaX ? Is there a way to make this
> more transparent ?
>
> - Would it be possible to layer the approaches ? Personally, I see the
> main benefits of a STaX parser in the context of XML data binding that it
> would be absolutely easy to restrict the scope of processing during e.g.
> unmarshalling. In other words, within a biggish XML document navigate to a
> (smaller) subset and only use this subset as the input for unmarshalling.
> Such a layering could be achieved by creating an adapter that sits between
> the StAX parser and the UnmarshalHandler (which implements SAX
> ContentHandler), and translates STaX events into SAX events. This way, we
> would avoid having to completely write a new STaXUnmarshalHandler (and all
> the logic currently sitting in UnmarshalHandler).
>
> Werner
>
>
> 建坛林 wrote:
>
> > 1.introduction marshalling is the processing of convert a Object into
> > xml(or other structured) file, while unmarshalling is the reverse processing
> > of marshalling. This techonology is very useful in data binding and data
> > transfering.
> > Marshaller/Unmarshaller is the very object that responsible for doing
> > these work. For marshaller/unmarshaller to do the marshalling work, it need
> > the help of a xml parser. There are two kinds of xml parser nowaday:one is
> > based on dom model, the other is based on stream model.As to the latter one,
> > we got sax and stax. sax is a push parser, while stax is a pull parser. I
> > think castor's purpose of switching between the sax and stax is to make
> > castor more adaptive to different situations.
> >
> > 2.solution
> >
> > i think the work should be done to the class Marshaller and
> > UnMarshaller in Castor source.
> > Make Marshaller.java,UnMarshller
> > .java upper class instead of final class
> > class Marshaller {
> > private int parserType;
> > Marshaller marshaller = new SAXMarshaller() ;
> > ...
> > public static void marshal(Object obj,Writer writer);
> > public static void marshal(Object obj,int parserType);
> > public static void marshal(Object obj,Marshaller marshaller);
> > ...
> > public void setMarshaller(Marshaller marshaller);
> > public Marshaller getMarshaller();
> > ...
> > }
> > class UnMarshaller {
> > private int parserType;
> > UnMarshaller unMarshaller = new SAXUnMarshaller()
> > public Object unmarshal(InputSource in){
> > unMarshaller.unmarshal(in);
> > }
> > public Object unmarshal(InputSource in, int parserType);
> > public Object unmarshal(InputSource in,UnMarshaller unmarshaller);
> > ...
> > public void setUnMarshaller(UnMarshaller unMarshaller);
> > public UnMarshaller getUnMarshaller();
> > ...
> > }
> > this Un~/Marshaller keeps the common methods of SAXMarshaller and
> > StaxMarshaller,
> > default use a SAXMarshller in order to make the existed code
> > unchanged;we change the Marshaller by using the specific constructor and
> > setUn~/Marshaller method. In this case,
> > it's flexible to switch from sax to stax,vice versa. It seems this
> > pattern is much more like
> > the strategy pattern. we just abstract the algorithm of un~/Marshal. and
> > it's flexible to
> > switch between these algorithm.
> >
> > the former Marshaller.java can be a SAXMarshller.java and
> > SAXUnMarshaller.java.
> > class SAXMarshaller extends Marshaller {
> > ...
> > }
> >
> > class SAXUnMarshaller extends UnMarshaller {
> > ...
> > }
> >
> > we can add by the following new Implementation of Marshaller
> > class StaxMarshaller implements Marshaller {
> > ...
> > }
> >
> > class StaxUnMarshaller implements UnMarshaller {
> > ...
> > }
> >
> >
> > make MarshallingHandler ,UnMarshallingHandler upper class instead of
> > final class just like
> > we did to Marshaller,UnMarshller
> >
> > the specific work we have to do is in implemented a new
> > StaxMarshallerHandler and StaxUnMarshallerHandler
> >
> > to implement the Un~/Marshalling in stax way
> >
> > class SAXMarshallingHandler extends MarshallingHandler {
> > }
> >
> > class SAXUnMarshallingHandler extends UnMarshallingHandler {
> > }
> >
> > class StaxMarshallingHandler extends MarshallingHandler {
> > }
> >
> > class StaxUnMarshallingHandler extends UnMarshallingHandler {
> > }
> > And the specific implementation of StaxMarshallingHandler is associated
> > with how to map
> > a object to xml(and the reverse process).The detail of this can refer
> > the implementation
> > of StaxMarshallingHandler(former MarshallingHandler).
> >
> > 3.self-introduction
> > http://docs.google.com/Doc?docid=dc42tcq9_88gtxts6fv&hl=en <
> > http://docs.google.com/Doc?docid=dc42tcq9_88gtxts6fv&hl=en>
> >
> >
> > Jiantan Lin
> >
> >
> > 2008/4/3, Werner Guttmann <[EMAIL PROTECTED] <mailto:
> > [EMAIL PROTECTED]>>:
> >
> > HI,
> >
> > I have recently asked all the students that have submitted an
> > application to be mentored by one of the existing Castor committer
> > sto subscribe to this mailing list, so that we can ask questions
> > about their proposal and vice versa.
> >
> > Can I please ask all students to introduce themselves briefly, and
> > once again describe their proposals. It's especially the benefits
> > for the project that I am personally interested in.
> >
> > Thanks
> > Werner
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> > http://xircles.codehaus.org/manage_email
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
