magpiebrain

“Rome”:http://wiki.java.net/bin/view/Javawsxml/Rome is another Java API which provides RSS parsing capabilities. Unlike the more mature “Informa”:http://informa.sourceforge.net it also supports Atom. Their comparison with Informa makes interesting reading – they state that Informa is hard to use! The mind boggles – here is how you can parse a feed:

FeedManager feedManager = new FeedManager();
FeedIF feed = feedManager.addFeed(getUri());

What is complicated about that? It’s true that Informa doesn’t support Atom yet, but that is a trivial task and support should be in soon (Niko is working on it now). Their only other complaint seems to be that Informa can only 1.0 and 0.91 in output – this is a valid criticism but RSS output never core to Informa’s goals. In any case adding support for other export mechanisms is trivial but to my knowledge has never been requested by anyone.
Continue reading…

In a recent trend of technologies being used as verbs (think _googling_, and err, well something else) of late I have been mostly Naked Objecting. For those who don’t know, “Naked Objects”:http://www.nakedobjects.org/ is a framework which allows the developer to quickly roll an application which provides both a UI and persistence layer simply by coding a domain model (for a better overview see ” Introduction To Naked Objects”:http://today.java.net/pub/a/today/2003/07/15/nakedaddress.html over at Java.net). Thats the good side.

That bad side is that the built in default ‘lightweight’ UI just plain sucks. It makes heavy use of drag and drop which is not in itself a bad thing, however its a jolt for those users more used to a standard UI, and no non-drag and drop alternatives are provided. It is also ugly, and not that intuitive. Luckily, Naked Objects make it fairly easy to roll your own UI for it, something I’ve been playing around with over the last few days.
Continue reading…

With a view to adding “Atom”:http://atomenabled.org/ support to “Informa(Java RSS API)”:http://informa.sourceforge.net/, I started looking into the specification in more detail. Just before I started looking at adding support for the syndication format, and found out that Niko (Informa’s product manager) was already looking at it. Instead, I decided to look at the posting and editing API. A “WSDL(Atom’s WSDL file)”:http://atomenabled.org/developers/api/AtomAPI.wsdl file was available, but “Axis(Apache Axis Web Services API)”:http://ws.apache.org/axis/ wasn’t too successful at converting it into a Java API. To get wsdl2java to actually process the file, I had to remove the @DELETE@ operation. I then hit the limitations of my knowledge as far as we services are concerned, so this has been put on the back burner while I read over some tutorials. I’ll keep you informed as to Niko’s progress on adding Atom syndication support to Informa

Using “HttpClient(Apache Commons – HttpClient)”:http://jakarta.apache.org/commons/httpclient/ I knocked up a simple Java API for “del.icio.us(del.icio.us – the social bookmark manager)”:http://del.icio.us/. It worked, but I quickly hit limitations of what the “del.icio.us API(Documentation for the del.icio.us API)”:http://del.icio.us/api/ itself would let me do – for example there is no way to get all bookmarks for a category. I sent off a feature request, so we’ll see what happens – but for what I wanted to do the current API isn’t good enough.

HttpClient itself did exactly what I wanted, which I guess is all you can ask of an OS project. The documentation was a little lacking, and the dependencies on “commons-codec”:http://jakarta.apache.org/commons/codec/ and “commons-logging”:http://jakarta.apache.org/commons/logging/ was annoying, however it worked well and gave sensible errors when required.

Along the way I looked at using “XStream”:http://xstream.codehaus.org/. I was planning to use it to process the results from the calls to del.icio.us, but the nature of the XML meant that this isn’t possible without transforming the results first. I would have no hesitation in recommending XStream for XML serialization, assuming you aren’t already constrained in the nature of your XML schema.

For some time now I’ve been using “@DateFormat@(DateFormat JavaDoc)”:http://java.sun.com/j2se/1.4.2/docs/api/java/text/DateFormat.html (actually “@SimpleDateFormat@(SimpleDateFormat JavaDoc)”:http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html) to parse user inputted dates it situations where a decent date chooser wasn’t available. Some simple bit of code like this would normally suffice:

private static final SimpleDateFormat DATE_FORMAT = new SimpleDateFormat("dd/mm/YYYY");

...

try {
  DATE_FORMAT.parse(someString);
} catch (ParseException pe) {
  //date is invalid
}

I learnt two things about this approach. Firstly, @DateFormat@ is _not_ thread safe. This fact was only documented in Java 1.4 despite it having never been thread safe. This is one of those things you learn, and is easily put right.
Continue reading…

I have long since come to the conclusion that JSP pages are evil. Not just bad, oh no. Nothing which can result in such unmaintainable crufty code can be considered merely bad – only evil will suffice. This opinion has been reinforced over the last few days, and this single gem stands out.
I was using a struts logic tag (asshats, I have no choice in this – the first person to tell me to use webwork instead is getting eaten by rats) to assert a boolean condition. It looked a little something like this:

  I hate JSP

For some reason even if @boolProperty@ returned @false@, “I hate JSP” was still being printed out. It being late in the day (and a Monday) I was slow to spot the closing @/@ on what I took to be an opening @logic:equal@. Despite the fact that I had a closing @logic:equal@, no parse error was thrown. Apart from the fact that a @logic:equal@ tag is of no use to man nor beast without a body (and therefore a validation error should of been thrown by Evil Struts) I would of expected the JSP compiler to notice an extra closing @logic:equal@. Of course assumptions are a dangerous thing when it comes to JSP…