englishteeth.co.uk

I wanted to generate some sample XML from an XSD I was given and I was struck by the lack of resources outside of the over bloated Altova tools and their misguided clones much more heavy weight options that seem overkill for what I’m trying to do.

I was actually hoping to find a style sheet that could do the job, but I had no luck.

Along the way though, I did find Liquid XML Studio which in it’s freeware incarnation has some nice schema viewing, editing and generation features. There’s also an integrated web service browser



and although, I haven’t played with it much yet, there’s an XPath expression builder in there too.



My only disappointment is the lack of XSLT support, at least in the freeware version. I’m looking for a reasonable successor to MarrowSoft Xselerator which is no longer supported or being sold by TopXML. Xselerator is not compatible with Microsoft Internet Explorer 7, which I has not actually proved a problem for me yet, but it’s days must be numbered.

I’m not adverse to paying for software (Xselerator wasn’t free), but I must admit to being put off a little by hobbled versions. An issue covered much better than I could by Jeff Atwood, here.

My favourite Cyberlink love/hate thing comes to mind; Power DVD Ultra, Power DVD Deluxe, Power DVD Standard or Power DVD OEM. Mmm, now let me see… do any of them work reliably?

Having come across Alex Miller’s blog, I’ve enjoyed a number of his posts. However, whereas I am definitely in-line with his dislike of the Singleton pattern, I couldn’t agree with his conclusions on the use of the template pattern.

1. Communicates intent poorly - The template method pattern is often used as part of the effective API in some mini-framework where the framework user is expected to subclass the template class. My experience has been that it is difficult to communicate that usage intent to users of the framework. Often the template class has some non-private methods that are exposed for use by the framework but are not intended to be used by the framework user, some that are intended to be overridden, and some that are both. Also, you may need to say whether the super’s version of the method can, should, or must be called. Communicating all that clearly is impossible in an API of any complexity.

I think that this describes a poorly implemented template. Certainly I agree that the pattern (or any other), can be misused, but when applied correctly I have found it very useful in directing correct usage and taking away the worry that it what needs to be done gets done.

Let me try to concoct some example that is illustrative while not having so many holes in it to detract…

Take the struts Action for example.

It quite conceivable/normal that within an application some high level activities that are common to all actions find their way up into some super class that extends org.apache.struts.action.Action

As a result is is quite common to find implementations of the abstract execute method in Action that look something like

public class NewAction extends TopLevelApplicationAction {

    @Override
    public ActionForward execute(ActionMapping mapping, ActionForm form,
    		HttpServletRequest request, HttpServletResponse response)
    throws Exception {

	// Do the stuff that must always be done
    	super();

	// Do the stuff that My Action needs to do
	while(stuffToDo())
	{
		doStuff();
	}

    	return mapping.findForward(SUCCESS_FORWARD);
    }

I don’t like to see super(). It make me think what’s going on up there (which encapsulation dictates is none of my business) and it also makes me think what if it wasn’t called? This is basically relying on the implementer doing what is expected, rather than the design ensuring that it happens.

And this is where the Template pattern steps up to the mark.

Changing the TopLevelApplicationAction a little…

public abstract class TopLevelApplicationAction extends org.apache.struts.action.Action {

    @Override
    public final ActionForward execute(ActionMapping mapping, ActionForm form,
    		HttpServletRequest request, HttpServletResponse response)
    throws Exception {

	// Do the stuff that must always be done
 	while(stuffThatMustAlwaysBeDoneToDo())
	{
		doStuffThatMustAlwaysBeDone();
	}

    	return executeAction(mapping, form, request, response);
    }

    public abstract ActionForward executeAction(ActionMapping mapping, ActionForm form,
    		HttpServletRequest request, HttpServletResponse response) throws Exception;

This then constrains this implementation of this and removes the responsibility of calling the super class from the implementer of the specific action.

public class NewAction extends TopLevelApplicationAction {

    @Override
    public ActionForward executeAction(ActionMapping mapping, ActionForm form,
    		HttpServletRequest request, HttpServletResponse response)
    throws Exception {

	// Do the stuff that My Action needs to do
	while(stuffToDo())
	{
		doStuff();
	}

    	return mapping.findForward(SUCCESS_FORWARD);
    }

A bit of a noddy example, but surely that must be better than the first (and in my experience, the most commonly seen) approach!?

I haven’t been reading as much this week. I’ve been tired.

Though the titbits that have stood out have included:

• Andrew Tokeley’s blog here
• an application to turn you into a Simpson’s character here
• the home page of The Kills, who I saw on Friday here
• Gareth’s trouble with his new PS3 here
• and Alex miller’s blog, here.

How much more fun the internet has become …

From Joost: The Adventures Of Brisco County, Jr. - The Brooklyn Dodgers
Brisco (BRUCE CAMPBELL) and Bowler (JULIUS CARRY) help two orphans claim a valuable inheritance.

It had been quite a while since I looked at Joost, but an e-mail from them mentioning an old Bruce Campbell favourite enticed me back. But rather that watching much, I found myself experimenting with the built in blogging widget… with the above is the result.

As my dentist is persistently asking me, “is it safe?”…

Having been asked to make some enhancements to an existing on-line application, I checked out the code from source control and made my way to the tests. Well you would wouldn’t you!

Selecting the root of the test source, I right clicked and selected run as JUnit test.

It was horrible; like a train crash or something.

After about an hour, I’d removed the errors my correcting path’s and references in the configuration. Unfortunately, I wasn’t in a position to address all the failures since I didn’t know what was bad tests and what was bad code. (Though since the application was live, with no outstanding bugs, it seemed reasonable to assume that the tests were stale.)

Within the tests I was disappointed, though not overly surprised, to find database dependencies to a database on some server. Luckily, the server and the database instance still existed, but I wasn’t really sure what it was used for.

A couple of days after tiding up the tests I was tracked down by team maintaining the mail servers. It appeared that the application I was looking into had been firing emails off to now defunct addresses that were collecting in their dead letter box.

Mixing unit and integration tests is not big and it’s not clever. Dependencies like these may seem reasonable to the developer in the heat of implementation, but they are not safe and make the subsequent support or enhancement of that software much more difficult.

Please test responsibly.

I’ve borrowed the Marathon Man image from this post from Freddo Fungus.