New place, new lucks

This blog, much like my personal blog has finally moved to the domain of Crazy Red Panda. You can find the new blog, with the old posts, at http://javachaos.crazyredpanda.com/.

Blogger gave a great host and I appreciate what they're doing. Giving a free, reliable and easy to use platform for bloggers is very welcomed, and I can't stop directing people to it when they think about starting a blog, even though in Israel we have our own free blog platform (which I deem with a lesser respect).

Okay, that's it! I've spoken enough, just flock to the new site already!

When a framework uses itself

I think the most fun part of using a framework, except for having others use it, is when the framework or producing company is using the framework itself for some task.

Just like the Apache site running on an Apache HTTP Server, Atlassian's JIRA having their JIRA issues tracked by JIRA, and so on.

Soon I will be facing Feature Requests 1380359 and 1380356, namely generating XSD from Java classes and vice versa. Thinking about the task ahead, as I usually try to do, I realised that it should be fairly simple, at least from parsing the XSD document perspective.

You see, I could bind the XSD document schema to POJOs using X2J, read the XSD document into Java classes using X2JReader, and use these Java classes to create Java annotated code.

On the other way around, I could just use the already existing Analyser class to fill up the information in those Java classes describing the XSD, and then just write them down using the X2JWriter.

Ah... I love simplicity..

Related Topics
XML to POJOs: Alpha 0.1
XML to POJOs: Repeating Types
XML to POJOs Example: Contacts List

Bug in java.blogs?

I'm probably the only one to use the search option in java.blogs, which can explain the following image I received when searching for the term "ajax":



Interesting Topics
Contacts List Example
Converters in XML
Using the Mould

Using the Mould

Lately I've realised that the Analyser code in X2J is messy, and wanted to treat it to a better design. For those numerous people out there who do not know the X2J code (yet!), I will offer some explanation:

The Analyser's task in X2J is to take a Plain Old Java Object (POJO) and analyse it into a ClassInfo instance. This instance represents an xs:complexType in XSD terms, and contains information regarding the type.

This information includes two collections: One for ElementInfo instances, and one for AttributeInfo instances (representing the xs:element and xs:attribute respectively).

These XXX-Info instances have only getter methods for their properties; They are much like the Class instances Java provides, in a way.

The problem with Analyser is that all the XXX-Info creation logic is located inside it; Whenever new properties are added to ClassInfo it would require changing Analyser itself.

An idea comes to mind and it is called Visitors. Visitors allow separation between the object's inspection and the object's creation. The problem is, once an XXX-Info is created, it can't be changed (getters only, remember?)

My proposition, and what I use in X2J, is something I call a "Mould". Internally, it's nothing more than a Properties instance.

What makes it special is that it is accompanied by a set of Visitors which change the mould information as they inspect the analysed class, and a Factory class which takes a mould and creates an XXX-Info instance from it.

What more is that the Factory contains a "default mould", so that if visitors did not change certain values they will have a default value set in a pretty convinient way, and outside the Factory's logic.

Any remarks? Did I miss anything? I'd love to hear responses!

Related Topics
XML to POJOs Advatanges: @Converter
XML to POJOs Advantages: @PrimaryKey
Interesting Topics
XML to POJOs Example: Contacts List
Class Enum<E extends Enum<E>>