I attended the Denver JUG meeting tonight and definitely enjoyed myself. It helped that I got to see an old friend, but it was also a nice refresher on XSL-FO and a great overview on J2EE UI choices. The basic concepts meeting was on XSL-FO, which as far as I know, is mainly used for creating PDF documents from XML content. Apache's FOP is widely used for doing XSL-FO in Java.
So here's a question for you - if I want to produce PDF versions of my resume (in struts-resume), which technology should I use? I know it'd be fairly easy with XSL-FO, but what about JasperReports? I'd like an easy way for users to be able to upload new "templates" for the PDF version of their resume, so FO might be the way to go. In addition, I'd also like to implement the PDF-rendering technology that I'll likely use on a real-world project. Are there some good APIs to use?
I did some XSL-FO work a couple of years ago and it seemed pretty cool, but it required a lot of trial and error to get things looking right (as is the case with most XSL). My favorite tool at the time was RTF2FO, which allows you to create a Word document with the look you want, save it as an RTF, and then convert it to a FO (.fo) document. Pretty slick stuff - it looks like they have a free trial and it's only $50/machine. The project I used it on was only 3 weeks, so the trail version did me just fine.
The main presentation was delivered by David Curry, who seemed to be an expert on J2EE UI choices.
David Curry is Director of Systems Development for ADP/SIS, part of the ADP Brokerage Services Group. He and his team use J2EE with DHTML, XML and Swing to develop mission-critical desktop productivity applications for brokerage and bond trading firms.
The main thing that impressed me was that David has been developing the same application since 1992. The app started out as a PowerBuilder desktop app, and moved to an HTML app, then DHTML - and now they're moving to Swing. They recently chose Swing (with the help of JGoodies) over their DHTML interface because 1) Java Web Start makes it much easier to deploy and 2) it's much more responsive for users on dial-up connections. David mentioned that it's a good idea to break your app into many separate jars so users don't need to update the entire app for new releases (a.k.a. JNLP Versioning).
I've often argued that you can make a webapp do almost anything a desktop app can do, but I can't argue with the bandwidth thing. It does take a long time to download a webapp that has a lot of JavaScript, CSS and images that make it rich. David mentioned that Gartner expects HTML interfaces to subside in the coming years, and for rich UIs (like Swing and SWT) to become more the norm. In one sense, I hope they don't - the only reason I'm in this industry is because of my HTML/CSS/JavaScript skills. It's all I know. Sure, I could probably learn Swing, and I might even like it, but I'd rather not. Learning Spring, WebWork and Tapestry sounds like more fun. Of course, if they can support a Swing UI, then I've lost nothing by learning them. I know WebWork does, but what about Tapestry? Is it view-technology-agnostic?
On the other hand, Swing does have some advantages:
- There aren't as many choices. Desktop apps are desktop apps, they should look like them. A lot of webapp developers (including myself) can get caught up in making a webapp look like a great website. The web offers so many more choices for look-n-feel that it's hard to decide which is right. I spend more time tweaking UI code (JavaScript and CSS) than doing anything else.
- Java Developers can develop the UI. In my experience, I have a rare set of skills - a strong HTML/CSS/JavaScript background, and a firm grasp of Java. The industry rumor is that there's HTML developers and Java Developers, but they're rarely the same person. David mentioned that there team is nicely consolidated to 6 developers - and everyone knows how to program in all layers. This sounds like smart management to me, moreso than Swing makes your team more efficient.
The other side of the coin is that Swing will never replace many webapps. For instance, it could never replace Roller. Why would readers want to download a Java app to read this site. However, since most of you probably use client-side aggregators and client-side editors, maybe the shift to desktop apps has already started...
One thing I really like about TheServerSide's new look is the sunken input boxes (that light up on focus) in the top right corner. I noticed that Macromedia does this on a lot of their form's too. It's good stuff. Here's how easy it is to add this "feature".
In your stylesheet, add the following class definitions:
/* for cool looking "sunken" input boxes, from www.theserverside.com */
form#searchForm input {
padding-left: 4px;
margin: 1px 1px 1px 1px;
border: 1px solid black;
color: #777;
background-image: url(../images/input_white.gif);
}
form#searchForm input.focus {
margin: 0px 0px 0px 0px;
border-bottom: #ffdead solid 2px;
border-right: #ffdead solid 2px;
border-left: #c07300 solid 2px;
border-top: #c07300 solid 2px;
color: #000000;
}
Of course, restricting these classes to one form (as I've done with form id="searchForm") is optional. Then in your form's input fields, add:
add a couple of onfocus and onblur event handlers:
onfocus="this.className='focus'" onblur="this.className=''"
You'll also need to grab the background image and put it on your site. If you're adding this to a form in your webapp, it might be easier to add all the event handlers with JavaScript:
var inputs = document.getElementsByTagName("input");
for (i=0; i < inputs.length; i++) {
inputs[i].onfocus=function() {this.className='focus'};
inputs[i].onblur=function() {this.className=''};
}
Thanks to the guys at TheServerSide for showing me how to do this - I dig it.
I learned about Macromedia's Flex from the JavaLobby Newsletter this morning.
In essence, Flex is a presentation server that sits on top of a standard Java servlet container like Tomcat and provides the ability to use the Flash player and an updated scripting language to manage the client-side user interface of a web application. The Flex Runtime Services provide management of server-side security, connections to data sources, and so forth. The Flex Class Library provides support for a full set of server-side flash components that can be accessed via an XML markup language currently called "MXML" (which is going to change before the product release.) MXML contains the tags for the widgets in the Flex Class Library and allows you to express rich user interfaces succinctly.
I've always liked Flash, but I'm also a sucker for eye candy and cool-looking UIs. If Macromedia could make it possible to create flash files with a markup scripting language, like I do HTML/JavaScript for JSPs - I think they'll get a winner. If we're forced to use IDEs and other tools to drag and drop components - I won't bite. I'm too used to typing vs. point and clicking. I don't use Dreamweaver for HTML - why would I start now?
However, I do have a friend who is an awesome Flash Animator - it'd be cool to hook up with him someday to create rich web UIs. Only problem is - I think it'll be tough to find a client that prefers a flash interface over an HTML-based interface.
What would be awesome is if I could use a RenderKit from JSF to create a Flash UI. The ability to write standard HTML/CSS and have it generate a Flash UI that could do everything like a desktop app - mmmmm, sounds sweeeeettt.
Update: The Flex JSP Tag Library might be just what I was looking for. I also found an article on Providing a Flex Front-End to your Struts Applications. In my opinion, the one reason that Flex won't work is that it will cost money - all other J2EE View technologies are free. Cheap is good though - it might work if it's a mere 50 bucks.
(although Erik Hatcher did mention it's easy to implement in Tapestry) and Struts Menu
