This post originated from an RSS feed registered with Java Buzz by Russell Beattie. Original Post: Gad XAOX! Finding the True Path to XAOism... Feed Title: Russell Beattie Notebook Feed URL: http://www.russellbeattie.com/notebook/rss.jsp?q=java,code,mobile Feed Description: My online notebook with thoughts, comments, links and more. Latest Java Buzz Posts Latest Java Buzz Posts by Russell Beattie Latest Posts From Russell Beattie Notebook

My thinking goes along the lines of this: I liked what happened when I separated out the XMLEnabled functions from my original XAO Interface. This allowed me to append this functionality on top of any object, which immediately becomes "XML aware." Basically, implementing that Interface makes the object responsible for its own XML serialization. As opposed to things like the Digester and other projects which grab a JavaBean or JavaClass and do the serialization for you. I never seem to like the XML that's produced. Have you seen the XML from the java.beans.XMLEncoder class? Bleh.

So stripping out those functions left me with a bunch of other methods, many of which I wasn't using regularly in my "real world" development. So I took a step back (another one) and tried to figure out exactly what I wanted and what the relationship between the Interfaces would be. After an intense chat session with Diego (THANKS!) I finally worked out what I wanted, how to do it sanely and what to call it. So without further ado, here's the new Interfaces:

public interface XMLEnabled {
	
	public String getXML() throws XAOException;
	
	public void setXML(String xml) throws XAOException;
	
}

--------------------------------------

import java.util.Map;

public interface XAO extends XMLEnabled {

	public String getXML(Map params) throws XAOException;
		
	public void setXML(String xml, Map params) throws XAOException;
	
}

--------------------------------------

public interface XAOX extends XAO {
	
	public String getXML(String xmlParams) throws XAOException;		

	public void setXML(String xml, String xmlParams) throws XAOException;
	
	public String getSchema() throws XAOException;
	
	public String getParamSchema() throws XAOException;
	
}

The last Interface is the newest one, called a XAOX, which is sort of a "pure" XAO in that it reads/writes XML and provides schemas to be self-describing. These are the methods that were in the original XAO, but I ended up not using regularly because I wanted more practical parameter passing in the form of a Map. The functionality, however, is important and I'm positive I'll be using it later on for Tags and inter-process communications, so I wanted it all there. But right now, to tell you the truth, I'm just throwing a bunch of web pages together in a closed-environment, so I don't *need* all that functionality.

A three level Interface hierarchy may be a bit hard to swallow, but here's my global view of how they fit. First is XMLEnabled which allows an object to produce and consume XML at a basic level. A great example is the XMLMap I made which is just a Map that when you call getXML() serializes the data it contains as XML. The second is the XAO, which assumes that an Object may return different XML based on parameters passed to it. The fastest way to pass those parameters is a Map, so this Interface uses that instead of more XML so as to be useful, yet practical. This is the Interface that I'm using the most because right now everything is in a closed environment where I control all the variables. The XAOX is an extension of the XAO which does the same thing, but for open environments where you may know only that a XAOX exists, but maybe not what parameters it needs nor exactly what type of XML you're going to get back. The Schemas allow this object to describe itself dynamically and the XML Strings allow parameters to come from just about anywhere.

I stacked them up in a hierarchy so I can just expand the XML enabled objects some day if I need to by simply swapping the Interface for the next one down the line. At one point I thought of making XAO and XAOX peers, but I thought that if I implemented both a XAO and a XAOX in the same class, what do I call it? a XAOXAOX? :-) Seemed cleaner (and less potential breakage) if I just created a hierarchy.

Final thought: I'm using JDOM. When the *hell* is that library going to come out of Beta?

-Russ

Comment