We are using XML files for facts in optaplanner solved examples. Can we use JSON instead of a XML file.
If yes please let me know how we can do it?
You can use whatever you want (including JSON): just replace the XStreamSolutionDao in the examples with your own implementation that read/writes in a JSON format.
As for Java technologies which can do that, that is out of scope for OptaPlanner, but take a look at:
XStream's JSON support
JAXB
Related
I am using Resteasy and GWT. For certain reasons, as many others have similar motivations, I am not using GWT-RPC for some of the functionality of the software I am working on.
I need to pass POJOs between GWT client and server by marshalling/demarshalling the POJOs into/from JSON.
OK, easier said than done because I need the POJO-JSON converters on both sides to match.
Q1. Is there a standard POJO notation in JSON? Is there an ietf RFC or ISO or ECMA that specifies the format of POJO notation in JSON? Or is it a free for all, libertarian anarchy?
Q2. Do Jettison and Jackson (when used with JAXB) and Autobeans produce the same JSON for POJOs?
Q3. This is the most crucial question. You can ignore the other questions above but you MUST answer this. Give me a combination pair of server-side and GWT client side JSONizer/deJSONizer that works together. For example, can I use Autobeans on client-side and use JAXB-jettison on server side and expect the JSONized POJO notation to be the same?
Q4. Is it possible to use JAXB-Jettison or JAXB-Jackson on GWT client-side by including the java source code for JAXB, Jettison/Jackson in the whatever.gwt.xml file? Are there parts of JAXB, Jettison/Jackson source code that might e.g., depend on reflection, or non-serializable, etc that would not make it possible to use JAXB + Jettison/Jackson in GWT client code? If possible, please explain how?
~
I should clarify concerning Q1:
I am not asking about RFC for JSON. I am asking about JSON POJO format. When a POJO is converted to JSON, everybody does it their own way - so, I am thinking that there should be an RFC to standardise the way and format a POJO is converted to JSON. Is there a standard or not? !!I hope your answers should not quote me the RFC for JSON!!
~
What about
Someone needs to tell me about
badgerfish on GWT client
and GWT client-server matched JSON-RPC.
There is no standard for mapping, but I would claim there is obvious simple mapping, given simplicity of JSON format, and de facto standard of Java Beans (i.e. mapping of set/get methods to logical property names). One of few exceptions is Jettison.
Jettison is not as much a JSON/POJO library as it is JSON<->XML library: it converts JSON to XML API calls (and vice versa), to allow use of XML tools such as JAXB for XML data binding, on JSON. But the cost here is that JSON it produces and consumes has extra complexity which is only needed to work with XML APIs. And this is what makes it non-standard compared to the usual straight-forward bindings like used by Jackson, GSON, Flex-json and other "native" JSON libs.
I would recommend not using Jettison unless you really, really must for some reason. Not even if you produce both XML and JSON -- usually you are better off mapping JSON to/from POJOs using JSON tools, and XML separate to/from POJOs (using JAXB etc).
Jettison was intended to bridge the gap between (then) more mature XML tools and newish JSON format. But there isn't much benefit nowadays when there are dozens of mature JSON libraries available.
JSON is just a subset of JavaScript, it was "invented" by Douglas Crockford. Here is the RFC for application/json: http://www.ietf.org/rfc/rfc4627.txt?number=4627. So any of your server side solutions should create the same result.
We are using RestyGwt ( http://restygwt.fusesource.org/ ) on the clientside and it works like charm. Its JSON encoding style is compatible with the default Jackson Data Binding so it should work with Jackson as well.
I want to create the generic XML parser so that I want to reuse much of code
Use case is I have to parse 10 XML web servers, and all of them have different data So How can i create generic XML Parser so that i use most of the parsing code
Using libxml2 for XML parsing and XPath queries in Cocoa
Use one of the many XML libraries, such as TouchXML or Google's. These will parse documents into object trees, among other things.
Use NSXmlParser I think it helps you !
Sorry for my question. Actually I didnt knew about the JSON, I want to parse the XML file by some new technique. Can anyone help?
In the same way that apples and oranges are both eaten, yet one fruit does not eat the other.
You cant parse XML using JSON, since both are data formats. In other words they cant be used to parse each other, since they are only data "containers", that means that their only purpose is to give data a specific format.
If you want to parse XML, you use a XML parser.
If you want to parse JSON you use a JSON parser.
You may want to change the question wording, but the answer probably is this:
http://code.google.com/p/json-framework/ (also on github https://github.com/stig/json-framework/)
Kickstarter: http://mobileorchard.com/tutorial-json-over-http-on-the-iphone/
I've loaded an XML file as NSData into memory and parse over the elements using NSXMLParser. Although it works, it's a very ugly and hard to maintain code since there are about 150 different elements to parse.
I know there are nice third-party solutions, but I want to keep it with the iPhone SDK for purpose of practice and fun.
So I thought: Why not convert that XML file into an NSDictionary? Having this, I could use fast enumeration to go over the elements.
Or is it just the same amount of ugly code needed to parse and process an XML right away with NSXMLParser?
Would I build up an NSDictionary for every found node in the XML and create a huge one, containing the whole structure and data? Or is there an even simpler way?
NSDictionary cannot read any random xml format. It can only read xml in a specific format which is the plist format.
The plist actually predates xml and the current plist format is just an xml version of the original. The name plist is a contraction of "property list" as the files define the properties of an instance of a class. Therefore, all the xml tags in the file must define elements of an instance of class that implements the NSCoder protocol.
So, yes, if you start with arbitrary xml you must laboriously parse it to convert it into an NSDictionary or some other class.
I wouldn't bother writing a parser from scratch for any reason except as a learning exercise. Every single xml format requires a different parser. It's better to use an existing parser so that 80% of the work is done for you. In a real project, you will end up doing that anyway.
There are many parsers there (e.g. XPathQuery, TouchXML etc.).
Hi dontWatchMyProfile,
You should better user NSString XML format. For this format, I have a little lib converting easily
http://bcaccinolo.wordpress.com/2010/11/14/xml-to-nsdictionary-converter/
I hope it might help.
Cheers,
Benoit
i've not tested this code yet.
http://troybrant.net/blog/2010/09/simple-xml-to-nsdictionary-converter/
I'm writing a couple of classes that generate xml file. (Details probably not important at the moment).
I wondering the best testing strategy is.
I don't want to re-write the xml generation code just to compare the output, when I could write the file to disk and compare it at certain milestones (the xml spec won't change often, like once or twice every couple of years)
I'm more interested in testing the behaviour of the architecture instead of the getters & setters
Options that come to mind:
rebuilding the xml file in the testing environment and comparing the string representations
manually checking the result (writing to file, etc)
rebuilding the xml file in memory in the testing environment and comparing the in-memory elements.
Virtual Bonus if you know any libraries for C++ and/or Google Test.
Ideas?
Have you considered using XSD's and validating your XML to the XSD? You didn't mention if it was content or structure you were testing for (probably both).
If it validates, it will test the structure of the XML will conform to the required structure.
In the past I've approached this two ways:
Compare the xml file against the result stored as a string in the test file. This is easy to implement, and unless you are wanting to generate variations of the xml file for testing purposes, the string comparison method works fine.
In the case where you have a xml file writer and reader, you can compare the original with the round trip result.
I agree with you that you shouldn't replicate the logic to generate the file in the test function, just for the purpose of testing. Also, I would try to avoid the need to write to the file system -- this is unecessary dependence on the file system, and would probably result in slower running tests.
You might consider using XML Unit: http://xmlunit.sourceforge.net.
It provides JUnit extension classes which can be used to assert equality
of XML files.
You might consider an XML diff tool. There is a free one available on MSDN: XML Diff and Patch Tool.
I see you are looking for C++ tools. In that case, libxmldiff might be more suitable.