Direct Manipulation Java Swing GUI Talk

At the St. Louis Java User Group meeting on Sep. 8, 2005, I gave a talk on building “Direct Manipulation” user interfaces with Java Swing. Here are the slide and code from that talk. The slides are quite limited, as the talk was spent almost entirely in the code – this is the kind of talk I prefer to give, with a lot of technical depth crammed in to the time allotted. Unfortunately this makes it somewhat less useful for people who weren’t at the talk; I’ve thought of making a “screencast” of the presentation for that reason.

Source Code and Presentation: SwingTalk.zip

Update: The sample code that got the most attention was the “flying boxes” code in the swingtalk.ordering package; you can try it now via Web Start.

Update: I presented this code again at the St. Louis Code Camp on May 5, 2007. Alex Miller picked it up and revamped it to use the new Swing Application Framework stuff coming (most likely) in Java 7.

Looking for a Web App Generation Tool

I’m looking for a tool that makes it astonishingly easy to generate a web app that facilitates the editing of the contents of a bunch of database tables. Details follow…

I’m looking for a tool that makes it astonishingly easy to generate a web app that facilitates the editing of the contents of a bunch of database tables. I want to specify:

  • which tables to allow editing (and viewing)
  • which fields to allow editing (and viewing)
  • which fields to show dropdowns for (rather than making users type IDs)
  • what captions to use for all table and column names
  • constraints to enforce
  • constraints to notice and complain about, but not enforce
  • a reasonable user management system for the web app (login/password/rights/etc.)
  • rules that define row-level security, i.e. allow users to edit some rows of a given table but not others

I’d like a “generative” tool, one that spits out a fully functioning app which doesn’t depend on the original tool for runtime infrastructure.

The specification of the things above can be mostly textual. Drag-drop-UML doesn’t excite me all that much (though I’ve used such beasts for Java work before). The generation process must be customizable, since no tool is likely to meet 100% of my present and future needs.

The generated app will preferably be in PHP or Java. PHP seems reasonable as it is ridiculously easy to get up and running (at most, a few packages to isntall in a common Linux distro), and Java is reasonable because I use it heavily for other purposes anyway.

It should be possible to support several common DBs (SQL Server, MySQL, PostgreSQL) with the flip of a switch or two.

The generation process should act like a build process – i.e. the “source” of the application would be the specificaiton file plus perhaps a few files work of manually tweaked code.

OK, so I’m asking for a lot.

… but there are dozens (or even hundred) of tools out there, both commercial and open/free, that meet at least some subset of the above. I Googled for a few minute and was overwhelmed at how many there are to look at.

A good starting point is the Code Generation Network, and a few of the specific tools I saw are phpCodeGenie, PHPMaker, Camino, Jag, JRpt, etc.

Of course, it’s entirely possible that none of them does everything I need – but that’s OK too, there is another layer of tools out there that make it easy to get start with my own generative approach: FMPP, Jostraca, etc.

Enough hoping for tonight. If anyone out there has had a very positive experience with any of these tools, for the kind of problem I’m looking to solve, I’d love to hear about it.

A few clarifications, after the initial post:

  • For this particular need, I prefer a generative approach to an “executable model” approach, though I think the latter might be the long-term winner in MDA.
  • Yes, I know that I’m mostly asking for DB-centric CRUD operations, rather than a domain centric behaviour model. I have plenty of time for the latter approach (with lots of Java code, Hibernate, perhaps even a rules engine) in other place, but for today’s need, which is for the “admin” side of an application, DB-centric CRUD will do the job fine, with a little help from constraints, validation, etc.

JAR Bloat

I am surprised at how large the main client application JAR file is on my current Java project. I have a pile of source code which I have written over the last few months; it contains no generated code and no outside code (that stuff is in other jars).

This body of code results in a 506K JAR file. About 10% of that is because it is a “signed JAR” (An aside: it appears that signed jars actually actually sign each thing inside the JAR… much far higher overhead than .NET’s igned assemblies, which sign the whole thing as a chunk. I think .NET is on to something good with Assemblies with Sun missed with just-a-bunch-of-classes-in-a-JAR. Of course the latter has significant advantages also.)

Without the signing, the JAR is about 450K.

Javac optimization is on. There are ~350 classes in the JAR file. The JAR is compressed; wihtout compression it is around a megabyte.

– debug is on, so I get more helpful stack traces from the field when errant software somehow escapes our highly rigorous release process. Turning off debugdrops it to 424K signed / ~380K unsigned.

These numbers all seems enormous. The source code for the contents of this JAR, is only ~800K, and contain considerable comments, private identifiers, etc. My mental model of compilation suggests that it would produce tightly packed bytecode that tersely captures the executable essence of the source code in a small fraction of the bytes. This appears to not be the case.

Taking a look at Zoe, “Google for your email”

I tried out Zoe (http://zoe.nu) recently, having seen it described as “Google for your email”. Of course that monikor will make less sense with Gmail here.

Zoe runs in the background on your machine, acting as a (non-real-time) proxy for your incoming (POP) and outgoing (SMTP) email connections; you continue to use your existing email client, seamlessly, while Zoe catalogs, cross-links, and full-text indexes every message. It’s a slick idea, and I believe that a few years from now, the features in it will be built in to many email clients.

Zoe provides a HTML user interface, even though it is a local application; it worked fine for me with both IE and Mozilla/Firefox. I also use POPFile (which uses an HTML interface), so the approach didn’t bother me, but it’s quite different from a “rich client” experience. The primary thing to do in Zoe is
to search, and web browsers work well enough for search/results/browse interfaces.

Zoe is written in Java, and other Java app writers should take a look at how painless the expierence is there: unzip the application, and run it. From the web site Zoe appears to be Mac-centric, but it works the same way on Windows (and presumably Linux/etc.)

I ended up giving up on Zoe after a few days, though, for several reasons:

  • Too many files: Zoe stores each email message in a separate file, plus various
    other files for indexes. After importing several years of stored email, I
    had 63,000 files under my Zoe directory. Aodern file system doesn’t mind lots
    of files, but there is more to life than file systems – try copying 63,000
    files to another drive, or backing them up, and it become clear that storing
    every archived email message forever in its own file, doesn’t scale well.
    (By the way, the emails are stored in directories named for the year/month/day
    of the message – good idea!)
  • Rebuild needed: A couple of times I was getting obviously wrong results
    from Zoe searches, and had to rebuilt its indexes to correct it. Easy to do
    – a one-line command. Downside: Zoe was unaccesible and my PC was working
    hard the next two hours while it rebuilt. I’ve worked with full-text-index
    systems in the past, and believe that this process could be made much faster.
  • Bugs – I sometimes get a “java.lang.NullPointerException” when
    clicking on a link in Zoe. It will go away… if I wait through another 2-hour
    rebuild.
  • I’m apparently not clever enough to tell how the GUI works – lots of things
    are clickable in Zoe; with many of them it’s not clear where the link will
    go
  • Missing hits – the search in Zoe often files far fewer hits for a term,
    than I know exist in my mail archives. This might be related to the Rebuild
    issue, though.
  • Lack of threading – contrary to some comments I saw about Zoe, I am unable
    to find any feature/view in it where it shows a threaded mail conversation.
    This is my #2 feature needed to manage a massive email collection, right behind
    Search.

In spite of this, I’m very pleased to see Zoe out there, wish them well, and
encourage anyone with a lot of email to give it a try, if only get an idea what
it coming.