Re: From Pox to Pojo
On 11/10/2007, Pete Cordell <petexmldev@t...> wrote: > Well, we do an XML to C++ databinding tool (as you might have gathered from > the sig!), so I'll give my views... > > I would say whether databinding is the right thing for a particular > application depends very much on what the requirements are. > > I think databinding works best for the more data oriented applications. In > particular, mixed content is not very well supported. If your data is > generally data oriented, but has, say, a blob of XHTML in it via an xs:any > specification, then I'd still say databinding is still appropriate. You'd > use databinding to access the XTHML blob, and then process that using some > other technique (possibly some kind of third-party browser module). > > Also the more your XML data is a means to an end rather than an end in > itself, then the more likely databinding is going to be a good fit. By that > I mean the more you can treat the XML side of things as a black box for your > application, the more databinding will be good for you. That doesn't mean > that unmarshalling an XML instance into objects, twiddling them and then > marshalling them out again isn't appropriate. It's just that if that is > your entire reason for existence, then it might be considered a bit lazy and > you could probably do a more efficient job using something like XSLT or SAX. > (Although - I would do the lazy route just because I am more familiar with > it and already have all the tools!) > > If your XML data is very large (where 'very large' depends on your system) > then databinding might not be appropriate. This is because databinding > results in the entire XML instance being represented in memory. I've never > done any tests to get an idea of how the size of the XML instance compares > with the amount of system memory consumed, but I would expect the consumed > system memory to be less. > > Databinding is also very handy if your data persists in the application for > some time, and a number of different code modules dip in and out of it (such > as configuration data). Thanks for the reply Pete, to be honest I was losing faith in this list after such an on-topic subject recevied no replies... Anyway, I've gone down the hand coded route because even though it's basic data centric XML, I needed a bit more behaviour from the enumerations that I wasn't getting from the generated code. For example given this: <xs:simpleType name="item"> <xs:restriction base="xs:string"> <xs:enumeration value="009"> <xs:annotation> <xs:documentation>Not Applicable</xs:documentation> My ideal enum is something like: Item.Not_Applicable which makes the code most readable, and the value and the textual description are availabe through methods like Item.code() and Item.desc() Instead I get Item.INT_X_009 which is understandable given the enums value, and its understandable not to get the textual description available, but it just means the code that uses the enum isn't going to be as good, and I'd have to store/access the description in some other way. I suppose i could write an adapter layer, but it doesn't seem worth it in this particular case. On the plus side, an interesting thing with XMLBeans is that you can use XQuery to select the nodes after they've been parsed into pojos: http://xmlbeans.apache.org/docs/2.0.0/guide/conSelectingXMLwithXQueryPathXPath.html I've not had time to try this out but it looks interesting... cheers -- Andrew Welch http://andrewjwelch.com Kernow: http://kernowforsaxon.sf.net/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format