|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
This month I'm going back to programming for a while. I need a rest from the weirdness on the Talkback discussion in last month's column. I do intend to write more about theory issues in the future, however, but not for the next couple months.
I do need to make one clarification from last month's column. Many people interpreted my comments about user interfaces as
advocating heavyweight objects with billions of rendering methods in them. That's not what I had in mind. There are numerous
viable ways to create user interfaces (UIs) without exposing implementation details. The Gang of Four Builder and Visitor
patterns immediately come to mind. A simple drawYourself() method obviously can't work on anything but the most simple objects, and having 50 drawYourselfInThisFormat() and drawYourselfInThatFormat() methods is a nonsensical recipe for unmanageable code. Many people think I'm advocating that approach, however, so I apologize
if I gave that impression.
Since I've seen a lot of misunderstanding regarding the UI issue, I'll plan on showing you a few implementations of object-oriented (OO) UI-building approaches in future columns. I presented one such solution in JavaWorld a few years ago (see Resources), but I've built better systems in the intervening years. This current column presents a piece of one of these UI systems: an infrastructure class I've used in building client-side UIs in an OO way. It is not in and of itself a solution to the UI problem, but it's a useful building block.
Since the code samples are rather large, I'll break up the presentation into two chunks. This month is documentation and application code; next month is the source code.
Read the whole "Create Client-Side User Interfaces in HTML" series:
HTML is a wonderful thing. It lets you lay out complicated user interfaces with a minimum of fuss; it does a great job of separating UI structure and layout from business logic; it's easy to write; and it's easy to maintain. Abstract Window Toolkit (AWT)/Swing layout is, in contrast, annoyingly difficult to use. You must modify (and recompile) code to change the look of your screens, and the code for a trivial layout is itself nontrivial, extending to many pages. Wouldn't it be nice if you could specify your entire client-side user interface in HTML?
(I know that some of you will answer the preceding question with a rousing "No, it wouldn't be nice!" Many argue that HTML and a good user experience are mutually exclusive concepts, since HTML forces your user interface into "infinite cascading dialog box" mode. On the other hand, a lot of applications can leverage HTML effectively in at least some part of the user interface—for tabular reports if nothing else. You can't throw out the baby with the bath water.)
Swing's JEditorPane class, at first, seems to be an answer to the HTML-layout problem. It does understand HTML input after a fashion. For example,
the following code pops up a frame that displays some simple HTML text:
Archived Discussions (Read only)