The journey began with a search for a database for my desktop application TimeFinder. It turned out that there are at least 3 candidates if I would choose a simple and only one tier architecture:
- GORM
- NeoDatis
- Db4o
One tier applications would only make sense for some special uses cases like in my case for high schools with one timetable admin. But it would be a lot better if I could use sth. like remote GORM, remote object persistence or even an ajaxified web application. Yes. Why not? What, if I rewrite the UI from scratch and move from ‘Swing Desktop’ to web? But then again: which web framework and which persistent architecture?
A lot of people would recommend Grails (myself included) if I need a simple CRUD web framework, but for me Grails is a bit heavy weight (~ 20 MB) and I will have to live with at least 6 languages: GSP, JS, HTML, ‘Spring-XML’, Java and Groovy. I will need Java at least for the performance critical part: the timetabling algorithm.
Okay. Then, why not GWT or Eclipse RAP? GWT has Javascript compilation, which I am not a big fan of and Eclipse RAP requires pure Eclipse development, I guess. So what else? There are a lot of Java web frameworks (with Ajax) as I discovered earlier. My choice now was simple: Wicket, which is Swing for the web. But what if you don’t like Swing? Then you will love the ‘Swing for the web’ 😉 !
Wicket Features
From what I learned in the last days and from blog posts; Wicket is outstanding in the following areas:
- Separation of UI and code. You only have
- pure HTML no new syntax required ala JSP, JSF, GSP, velocity, … the latter one was the reason for not choosing click. No Javascript hassle … if there are some, then I trust the wicket community to fix them in wicket itself
- and pure Java. This is very good if you’ll someday refactor your code. And you’ll.
- You can create your own components easy and fast. You can even create ajax components without xml and js… only Java.
- A strong community (even a German book)
- No route file necessary. (This can be a disaster for manually managed JSF apps)
Okay. And the persistent layer? That was the reason for this journey … hmmh, there are already several different persistent ‘technics’ for Wicket available:
Hmmh, but I only need a very simple persistent layer. No complex queries etc. As I mentioned earlier I can even live with xml (for datastorage). I decided to look into db4o again (used it in gstpl which is the antecessor of TimeFinder) and into the more commercial friendly (LGPL) object oriented database NeoDatis. The latter one has an option to export to xml and import the same, this would be great so that I don’t have to think about database migrations (some refactorings will be applied automatically. see 1.10 in the PDF docs). Migration in db4o should be easy too.
While I was thinking about that, I asked on the Apache Wicket mailing list for such simple persistent solution. Jeremy Thomerson pointed out that there are even some maven archetypes at jweekend which generates a simple Wicket app with persistence for me. I chose the Wicket+Guice+JPA template and updated this to use Guice 2.0 and the latest warp-persist according to this post. After that I needed to make db4o or NeoDatis working. For the latter one I needed warp-persist-neodatis and for the first one I only needed some minor changes, but they took a bit longer.
Resources
For those who want to see the results, here are the 2 independent maven projects (Apache License 2.0) within my subversion repository (revision 781):
To try the examples just type ‘mvn install’ and run ‘mvn jetty:run’. The resulting war file is amazing small: under 6 MB!
Now point your firefox or opera to http://localhost:8080/timefinderwicket/
And here is the screenshot:
As you can see the localized warning messages are already provided and shown instead of “Please enter a value into the field ‘location'”.
To work with wicket is a great experience! In another project it took me about 10 minutes to convert a normal submit into an ajax one which updates only selected components. And then, in the NeoDatis project I initiallly developed my EventDataView against a completely different data item and moved the source nearly unchanged to the db4o project with the Event class! That is nice component oriented development. Okay, I did copy and paste rather then creating a maven submodule for the pageable list, but that wouldn’t be that difficult with wicket. Then as a third example I overwrote the navigation panel, which was easy too: Now instead of
<< < 1 2 ... > >>
it will be shown
First Prev 1 2 ... Next Last.
without touching the UI. You can even provide ‘properties’ files to apply easy I18n.
Coming Home
Wicket is like coming home ‘to desktop’ after some years of web development, especially in the UI layer. And guice perfectly meets my dependency injection requirements: pure Java.
To get all things right I had to tweek the initial example of jweekend a lot, but all necessary changes were logically and does not smell like a hack. As a first step I updated the versions of the artifacts and then I added a DataView from the repeater examples. The developed CRUD example is now built with dependency injection instead of the original locator pattern (ala DatabaseLocator.getDb()):
@Inject
Provider<ObjectContainer> oc;
Then the update mechanism and some other exception must be solved, but you only need to check out the sources and see what is possible!
As a side note
please keep in mind that there is a NetBeans Plugin for Wicket 1.4.x and an IntelliJ plugin for the same. For all NetBeans guys which are interested in ‘deploy on save’ feature you only need to enable ‘Compile on Save’ and then you can change code or HTML in Wicket, if you are running the application via jetty:run (jetty configuration is already done in the pom). Currently this works only with db4o as a standalone server. To my knowledge this way of UI prototyping can be even faster than with Grails, where it could take some seconds to be recompiled.
Conclusion
Dive into the world of Wicket right now!
to let me do an update for NetBeans 7.0!
Karussell 