the new app – what and how to make it

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…

the project…and downloading and installing Griffon

Background

I’m involved in a small software company in the U.K.; currently we’re updating our payroll package and we’re (well I’m) using Griffon to produce a small desktop application. We already have a small Java app. that takes the data for a leaving employee and prepares an XML file and uploads that the the Inland Revenue, the Griffon work will be an upgrade to this Java app.

The reason that we’re using Griffon is, in the main, because we have been re-writing our existing package using Grails and so we’re familiar with Java and Groovy. So it seemed reasonable to give Griffon a try, and here’s a description of that work. I’ll give more details of the actual function later.

I should point out that our work is currently on WINDOWS XP, we are looking to move our development towards Linux, but that’s for the future.

Downloading

This is an easy bit…the Griffon web site gives the instructions for downloading and there’s not much one can say about those – just do what it says. We just downloaded the latest 0.1.2 version, and actually took the ZIP.

Installing

Again just follow the instructions:

• make a new directory (say c:\griffon, and why not ?)
• unzip into there, WINDOWS unzip can do odd things if you don’t watch, so we manipulated the results so that we now have c:\griffon\griffon-0.1.2
• create new environment variable for GRIFFON_HOME  (=c:\griffon\griffon-0.1.2)
• add an entry to the PATH variable for %GRIFFON_HOME%\bin

and, essentially, that’s it, Griffon should now run.

Because you’ve set up the PATH, just open a DOS window and type ‘griffon’ and something should happen. If you are going to just try ‘griffon create-app’ be warned that it will create the application structure in the current directory.

Next time – what we want to do with Griffon…

start here -

Welcome to my blog about experiences with Griffon.

More to come soon….