Hello, Werner.Thanks for your reply and good suggestion. the problem you refer to does exists. At the begining, i myself want to implements a adapter to bridge the gap between these two Parsers. So i offers a much more obvious one. Obviously, it 's not a good one. I'll try to read more material to verify your suggestion. (i will describe it in uml in my next letter)
and there is another idea we can try as the picture in the accessory show:
as stax is attractive in filtering our preferable partical(event). we can
first refine the xml by stax then use the existed SAXhandler to finish the
rest
un~/marshalling work. but is it a adapter. it seems a bit not.
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
>
>
>
<<attachment: adpter.jpg>>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
