建坛林 wrote: > another question:There serveral companies that have implements the stax > APi.For example, the companies listed below. > > * Sun's Implementation - SJSXP <http://sjsxp.dev.java.net/> > * BEA Reference Implementation > <http://dev2dev.bea.com/technologies/stax/index.jsp> > * Oracle StAX Pull Parser Preview > <http://www.oracle.com/technology/tech/xml/xdk/staxpreview.html> > * codehaus StAX > <http://stax.codehaus.org/Download> > > which API package will we adopt? Good question .. ;-). In other words, I don't know yet. I will be part of your task to make this deciskion, or find a Java-based standard that allows us to plug in any STaX parser.
> 在08-4-4，*Werner Guttmann* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> 写道： > > > > 建坛林 wrote: > > 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. > > Well, it's not that it is a bad idea per se. I am just looking at things > from a different perspective. Well, quite some perspectives .. ;-). > > a) If we go for an approach where you build the StAX* classes from > scratch (without relying on existing cod base, that is), you'll b > creating lots of code that already exists in the current e.g. > UnmarshalHandler class(es). Now, I don't really like the idea of code > duplication, but trying to refactor this would clearly make this work > far bigger in size (and thus not really acceptable for the GSoC > program). > > b) As already mentioned, there's one thing that should not really > change, i.e. the classes the user interacts with. At least not in an > ideal world. I know that we now and then have to change the public > interfaces, but this should be as limited as possible. > > Having said that, one way to improve things for Castor XML in the future > is to introduce interfaces, which currently do not exist on the XML side > of things. > > Looking forward to your follow-up. > > Werner > > > 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] > <mailto:[EMAIL PROTECTED]> > > > <mailto:[EMAIL PROTECTED] <mailto:[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> > > > <http://docs.google.com/Doc?docid=dc42tcq9_88gtxts6fv&hl=en > <http://docs.google.com/Doc?docid=dc42tcq9_88gtxts6fv&hl=en>> > > > <http://docs.google.com/Doc?docid=dc42tcq9_88gtxts6fv&hl=en > <http://docs.google.com/Doc?docid=dc42tcq9_88gtxts6fv&hl=en> > > > <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]> > > > <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > > <mailto:[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 > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > ------------------------------------------------------------------------ > > > > > --------------------------------------------------------------------- > > 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 > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
