Recently I was playing with Millstone, an open-source "web user interface component library." It makes you feel like you're writing a Swing-style UI, in Java source, and it creates the web interface for you. The nice thing is that if you happen to like the default "theme" (look-and-feel, presentation details), you never to have to get your hands dirty with the HTML or Javascript details. I find the optional Eclipse plugin highly useful, as it features an automatic end-to-end refresh -- you edit the source, and suddenly, it has recompiled everything and refreshed a browser with the new UI (displayed within Eclipse).
Of course, many applications will require some kind of customized theme, which can be done by tweaking, or overhauling, the XSL stylesheets. I have not played sufficiently with XSL to just go in and do this, especially compared to the kind of sweeping changes I like to envision, but it's nice to know that the smart Millstone engineers have achieved such a clean separation that I can do this without modifying my application's Java source code.
One area I want to play with more was validation. Millstone has a nice model for this, with a Validator and Validatable and ErrorMessage classes. Validators can be composed and a bunch of them can be added to a Property or a component, and the ErrorMessage is something that can be stuck onto a component so it shows a little error icon where you click for more info. Of course that's the default behavior and can be customized. It seems like a pretty flexible interface. However, in my brief time I had difficulty getting my Validators to be invoked. According to the Millstone forums, the validation used to be completely automatic, and now you must invoke it explicitly. This doesn't seem surprising, as I'm guessing the automatic stuff didn't completely suit everyone, and enough users needed explicit control. But I had difficulty getting this going. My goal was to use a text field where the user would enter a port number, so I decreed that the text field is only valid when it has a number from 0 to 65535, or simply blank (where a default is inferred). At first I tried adding a change listener which would invoke the validator, but it didn't seem to be invoked after I typed an invalid value ("-1" or "abc") and hit "return". It's quite possible my page needs some kind of submit button, I don't know. When I set setInvalidAllowed(false) on my TextField, the validator did seem to run, and I would get the expected red error icon if I entered an invalid value. One interesting thing the system did on these errors is to reset the text field to blank. I find that intiguing, because I'm not generally used to a UI control changing its value on its own. Presumably you can override or nullify this behavior somehow, because I could envision the text field holding some long text string with a single typo, and the user looking on with dismay to see it disappear forever. Maybe the text field has an undo history, I don't know.
Despite this experience, I'm impressed with the Millstone package and would like to see it come more into the mainstream, because it looks like a well-designed package with plenty of room to grow.
Monday, April 24, 2006
Millstone
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment