Requirements
In essence this app is just a simple front-end to take in the data for a new employee, there’ll be a bit of validation and then, of course only if valid, it will be all packaged up into an XML document and sent to the IR. In the real application this data will be used to create a new employee record (well, with some exceptions if it’s someone who’s returning); however in our current hybrid state only some of the data will be sent to the interface modules to the COBOL package to create the record there because the old system doesn’t keep as much data as the new one does/will. However we will keep the XML document that has been sent and the IR responses (also XML documents). The upload processes and the COBOL interfaces have already be written in Java and we’ll just make use of those.
User Interface
I came to the first ‘stop and think’ moment over the UI very quickly. I’ll admit that it may be slightly more logical to look at the data model first but to some extent that is defined by the IR specifications so I started with the user interface. Our typical user knows about their business but probably wants to spend as little time on the computers as they can so the UI is very important. It can certainly break an application; a poor UI is going to cause problems, a good UI is going to smooth the user’s interaction with the software and that is to everyone’s benefit. In addition we plan to get the software out fairly quickly and be prepared to make amendments as required by the users, probably fairly minor, but in a general sense maintainability is very important; this is a small app and the last thing we want is to have minor UI changes costing significant developer time and effort.
So, I had to “stop and think” – how are we going to make the UI ? Well, Swinguilder, but of course. However I don’t really know Swing, I mean I’ve written Swing apps but that was courtesy of NetBeans GUI designer and, well, it just worked; and why should I want to understand how it works ? But builders are a bit different and do appear to require that the programmer has a fair degree of knowledge of the thing that they are building, and that was my conclusion after a few attempts. Anyway after some hours searching the web I discovered that the general consensus is simply “don’t use native Swingbuilder” and I see no reason to disagree with that.
So what do we use ? Well, there do appear to be a few alternatives; I looked at a couple but again decided to go with the one that seems the most popular: that’s MigLayout. In essence you can do what you want with MigLayout but far more simply than with native Swing, and with fewer lines of code and , to me, fewer lines of code do usually improve maintainability. Perhaps there are some UI features that you cannot achieve with MigLayout but we do try to keep UIs clean and simple and after a quick look at the documentation I was quite happy with it.
IDE, editors etc.
Finally I was almost able to write some code. Personally I like IDEs, perhaps, being of an age when I can remember having to write out coding sheets for card punch operators and then have to faff about with overnight runs etc. etc. etc., there does seem to me to be a benefit in having one bit of software that does almost everything you want in one place. As far as I’m aware, at the moment it is only NetBeans 6.7 that has any Griffon awareness (via a plugin). There’s just (that’s today) been a new Alpha version of the plugin released and Geertjan has said that he does intend to develop it further. I’m using it now; it gives you a Griffon project structure and quite a few features, obviously including the editor and ‘run’ facilities, which, at the moment, is all I need.
and next time I’ll actually develop something that runs…
