Posted by yamsellem in the early morning: March 17th, 2011
As an ubiquitous exchange format, XML is well implemented in java. But those implementations hide how they perform the data binding from a XML structure to an object graph. It leaves us helpless in front of an application giving XML as a plain old string. Because low level API (DOM, XPath) — focused on document structure — are tedious, major JAX-RS implementation (Jersey, CXF) have chosen the same high level API — focused on data —: JAXB. Let’s do the same.
Posted by Age Mooij in the late afternoon: February 3rd, 2011
Trying to produce bad quality code is quite hard when you are using Test Driven Development (TDD), even when you are doing it wrong on purpose.
Recently Iwein and me were preparing some labs for a developer training and the plan was to create some really bad quality Java code as a starting point. Students would then be asked to clean it up and add some new features, all this of course with the intent to show the effect of bad code quality on your ability to quickly add new features. This was going to be a piece of cake!
After some brainstorming for interesting standalone programming challenges, we came up with the idea of writing a JSON to XML converter. It should be able to take any valid JSON string and convert it into a simple XML representation. Out of habit and without really considering the option of skipping this step, we started with a simple failing test. Here it is:
@Test
public void shouldConvertTopLevelEmptyArray() {
assertThat(converter.convert("[]"), is("<array></array>"));
}
Simple, right? To implement our converter we decided to use the well known “red, green, as little refactoring as possible” anti-pattern, which we expected to result in lots of copy-paste duplication, very long methods, and the other typical code smells we all know and loath. Our first implementation approach was to go for some all-time favorite candidates for producing bad code: string manipulation and regular expressions. As Jamie Zawinski famously said: “When some people have a problem, they think: ‘I know, I’ll use regular expressions’. Then they have two problems.” We had created a sure thing recipe for disaster. It was going to be all downhill from here, or so we thought.
Posted by Wilfred Springer at around evening time: January 11th, 2010
There doesn’t seem to be an easy way to validate an XML document against a schema, so I figured I would roll my own library for it. Now, with that library, validating against a schema all of a sudden becomes easy. In the past, I hardly ever considered validating a document against a schema in my tests, but now I find myself doing it all over the place.
Anyway, I will just give a brief introduction. (And there really isn’t that much to talk about.)
First of all, let’s assume that you have a File reference to an XML file (xml) and a File reference to a RelaxNG schema file (schema) (more…)
Posted by Wilfred Springer terribly early in the morning: October 19th, 2009
If you happen to be in the business of writing software serving XML documents or consuming XML documents – and if you read this post, then there is a fair chance you are – then there is always one big challenge: how do you make sure your service or client is capable of dealing with all of the XML documents you could possibly expect to be passed around?
And if you happen to come from the test-driven world, the answer is obviously: by testing it. However, if you try to do that, things might be harder than you expect at first.
What about schemas?
Posted by Age Mooij in the late evening: July 25th, 2009
Earlier this week I ran into a missing feature in the Scala xml library and I ended up adding this feature myself, which turned out to be pretty simple.
I was trying to extract the text contents of an element in a piece of XML using the handy \ and \\ methods on scala.xml.NodeSeq. These methods allow you to extract sub-elements from an XML node in a way very similar to XPath, something like this:
val xml = <a><b><c>text</c></b></a> val c1 = xml \ "b" \ "c" val c2 = xml \\ "c" val text = c2.text
The problem I ran into occurred when I tried to use these methods to extract an element when one of its attributes had a certain value.
Posted by Jeroen van Erp around lunchtime: September 15th, 2008
In many JEE apps today, you almost cannot forgo XML. Whether it is in configuration, data structures or service interfaces, you will certainly use a number of XML files. In a recent project we had to deal with a number of external services which used an XML interface. Little did we know that we introduced a potential time-bomb in our application… (more…)
Posted by Balaji D Loganathan in the early morning: May 6th, 2008
I was trying to learn Adobe AIR and was looking for some good set of learning resources. I found the book “Adobe AIR for Javascript Developers” from Oreilly by and started reading it online. A cool book, the authors have done great job on presenting the topics as an easilit readable pocket guide. Soon after reading this book, i felt i got the right resource i want for now.
(more…)
Posted by Balaji D Loganathan in the early afternoon: September 20th, 2007
A short overview on some of the XML rendering tools that i have experimented with.
While the applications of XML is a very broad topic, this blog will focus only on some of the tools available to use XML electronic forms creation, submission and exchange.
Example : An electronic purchase order or Invoice exchanged between two partners.
(more…)
Posted by Jeroen van Erp in the early morning: August 17th, 2007
And walks and talks like XML, it surely must be XML. Yes, well how wrong you can be about assumptions is once more shown in this blog.
One of our clients has an application through which videos are streamed. They do this by providing a browser embedded player, or your stand-alone Windows Media Player with an ASX file. The ASX file tends to look like this:
Posted by Robert van Loghem just before lunchtime: May 23rd, 2007
It’s wednesday again! and that means a new Xebia Podcast!
This week we continue the Enterprise Java Application Performance Top 10, numbers 8 and 7 with Vincent Partington and Jeroen Borgers.
Number 8 – Incorrect usage of Java EE
More information about number 8 can be found here.
Number 7 – Unnecessary use of XML
More information about number 7 can be found here.
So download the podcast here or better yet! subscribe to one of our rss feeds on http://podcast.xebia.com