Matt RaibleMatt Raible is a Web Developer and Java Champion. Connect with him on LinkedIn.

The Angular Mini-Book The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

RECENT ENTRIES


Tag Cloud


abbie appfuse birthday denver family grails gwt jack java javascript jhipster jsf linkedin maven roller skiing softwaresummit spring springmvc struts2 travel trish vacation webframeworks wicket
« MD-5 password encryp... | Main | A Wiki to Watch »
Wednesday January 14, 2004

DJUG Meeting: The Future is Swing

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...

Posted in Java at Jan 14 2004, 10:09:17 PM MST 6 Comments
Comments:

Spring has support for using PDF as a view technology. Haven't used it myself, but I know it's in there somewhere.

Posted by Thomas Risberg on January 15, 2004 at 06:09 AM MST #

On PFD:
We use bigfaceless at my company. This is a commercial package, but not overly expensive. They have their own mark-up language to specifiy the layout, which similar to HTML with style sheets (CSS2).

On the full client Swing thing: I disagree that full clients will ever get en vogue again. The company I work for (big global financial corp.) forbids the introduction of non-browser based apps. From a roll-out perspective, anything that has to be installed on a desktop, no matter how good Java Web Start or Microsoft SMS is, it will fail somewhere, sometime (Murphy?). The additonal costs of support, especially in more remote locations, are significant. With webapps: you deploy 'm in one, maybe two locations. Anything that goes wrong can be dealt with on the spot by the deployment team with assistence of developers.

Perhaps I am baised, talking from the p.o.v. of a big company. Maybe so. But the operational benefits of web-based application are undeniable. We currently have a separate unit of 6-7 people that test all application that are rolled out to the branch network. They have a complete branch replicated, which is a pain, because not all branches are standardized. All software has to pass their 'branch-ok' test or it cannot be rolled out. The regions then have again their own intake and pre-roll-out test.

Anyway, my 2 cents.

Posted by Jaap on January 15, 2004 at 07:58 AM MST #

!Thomas - thanks for the tip. I did some research and it looks like [Spring|http://www.springframework.org] uses the [iText|http://www.lowagie.com/iText/] library. The example from Rod's book makes it look [pretty simple|http://www.lowagie.com/iText/tutorial/ch01.html#steps] to create PDFs with it's API, but it doesn't (at first glance) look like it supports templating. The ability to ''template'' a PDF with XSL-FO sounds much more flexible. As always, choices are good.

Posted by Matt Raible on January 15, 2004 at 12:57 PM MST #

I don't know for sure which technology will dominate (Fat or Thin clients) but I saw David's talk last night and at the Rocky Mountain Software Symposium and wanted to point something out. The app that David's team developed had gone from very simple Main Frame App, evolved into a Fat Client, then went back to Thin Client in terms of a J2EE deployment. The reason they were going back to Fat is that the client wanted an extremely rich presentation and that took lots of bandwidth. David said they also saw latency slowing things down. The reason they're moving back to fat via WebStart is it was the best of both worlds. I agree that they can never be 100% sure that the problem isn't a local machine, but they can treat their deployment similar to a web deployment since the way they manage it through versioning the user only gets the jars that change and the users always gets the most recent copy when they start up. Deployment isn't that much different than a J2EE deployment - they still only deploy to one place which is where the jars are download from for the local clients. The only drawback can be if the client doesn't have admin rights to install the JRE via WebStart. I ran into that at work when I developed a small Swing app and had to login under my user-id in the clients NT boxes to install the JRE to run the app. Matt - If I've mistated anything feel free to correct me. There's my $.02 - Greg Ostravich

Posted by Greg Ostravich on January 15, 2004 at 05:47 PM MST #

I'm using Apache FOP on a rather large project for a client and, while it doesn't implement the full spec, it's been more than sufficient to meet most needs.

Posted by Nick Heudecker on January 16, 2004 at 06:00 AM MST #

Regarding XSL-FO vs. iText, iText is much faster at generating a PDF, if speed is a concern. iText doesn't support templating from a text file, but you can read PDF and manipulate them, perhaps there is a solution in that direction.
Regarding your Swing first advantage: Swing is immensely rich with the Pluggable Look And Feel approach. You can spend hours and hours doing your own PLAF, or finding the subtle bugs or needed customization in the PLAF you're using. Aside of those annoyances, it's still UI design, and it's easy to get caught in perpetual UI refinement.

Posted by Damien on January 19, 2004 at 01:40 AM MST #

Post a Comment:
  • HTML Syntax: Allowed