Friday, September 29, 2006

Back to Radiant

In one of my first posts I talked about Radiant. Having tons of other stuff to do, it dropped below my horizon. Because I am still on the mailing list, I saw a presentation passing by from Nathan Wright. The presentation is a beauty for first time Radiant users. I can highly recommend it if you like Ruby and are searching for something to build a simple site.

Because I can't find a download, I've put it on my home server for now. So here it is:

Radius, Content Management Simplified (5.6Mb)
Denver Derailed meeting September 27, 2006
Covers Radiant version 0.5.2 By Nathan Wright

Update 2006-10-02: Thanks to Luis Lavena for providing a more solid server.

Update 2006-10-04: The link above is now pointing to Nathan's own blog.

Update 2007-03-06: All previous links are now dead. I placed the copy on my home server back.

Thursday, September 28, 2006

Wicket for BSCs

Since I am finally getting to do a Wicket project (more then a year after I first learned about it), I subscribed again to the Wicket user mailing list. Initiated by an e-mail from Erik Brakkee, I started a thread to find out how to convince Big Slow Companies (BSC) to use Wicket and finally leave Struts in peaceful history.

There was only one criterion for the items in the list: they must be one-liners that are irrefutable so that there is no place for any FUD.

Together we came to the following points:

- Wicket enables scalable development. It is easy to split the work over many developers, it is even easy to split the work for HTML people and Java people.

- Wicket provides a natural programming paradigm familiar to Java and other OO developers. There is no need to learn new languages, Java and HTML are sufficient.

- The Wicket user e-mail list provides excellent support.

- Wicket has excellent feedback messages in case something goes wrong. Furthermore, Wicket is robust and shows no weird or unexpected behavior.

- Wicket provides excellent clustering support. When required, it is possible to optimize session usage.

Although there was some strong support for including reusability and maintainability I did not do so. I have yet to find BSCs that deeply care about these issues.

Thanks go to Eelco Hillenius for his infinite ability to promote Wicket. Thanks to Che Schneider for coming up with the TLA BSC.

Friday, September 22, 2006

Java voor Excel Quiz

Here are some projects:
- JExcel
- Java Excel API (aka JExcelApi)
- JXL
- POI

Which one does not belong in the list?

I'll post the answer in a few days with some more information on each project.

Update 2006-09-26

JExcel is a commercial library for for integrating Microsoft Excel into Swing applications. It will actually show an Excel sheet in your Java app (you do need Excel installed). From your Java code you can change the worksheets. Sounds neat, but I wonder who would want to use this. One thing I found is that the API seems to be a evolution of the following project: Java Excel API.

Java Excel API is an open source java library with which you can read, write, and modify Excel spreadsheets. I am currently using this one as it had some better blogs then POI. Although it does it works, I am not completely happy with it. The API is not consistent (for example: you can make something bold, but there is no obvious way to check whether a format is made bold) and the package structure and class names are kind of weird.

JXL is an umbrella for a couple of small open source java library with which you can build distributed Java programs with distributed class loading. I did not look much further into this. It seems that it tries to do JavaSpaces like things.

POI is again an open source project with which you can read, write and modify OLE2 documents including Excel and Word files. I have never used this, so I can not compare it to JExcelApi.

So the answer is: JXL.

Thursday, September 7, 2006

More portlet woes

I've got my portlet running for some time (see previous post). I even have a weird hack to enable file downloads. The Spring portlet MVC framework helped me a lot to structure the portlet really nice.
But now a colleague has started to write portlets as well. And guess what, he is as frustrated as I was. To make things worse, even with my previous Pluto experiences, there is nothing I can do for him! It is all so complicated with nondescript exceptions and configurations all over the place.

These 2 reasons (bad exceptions and configuration) are exactly the thing why Spring is such a joy to work with compared to using an old style EJB setup. And, you can even do better. The web framework Wicket gives you no configuration at all! And it still gets better: no more JSPs! Wicket to conquer the world!