SitePoint » Learn CSS | HTML5 | JavaScript | Wordpress | Tutorials-Web Development | Reference | Books and More » Java EE

Java 6 for Mac OS X Back on the Radar

Kevin Yank — Thu, 20 Dec 2007 00:43:18 +0000

Nearly two months on from the release of Mac OS X 10.5 (Leopard) and the resulting uproar from Java developers over Apple’s silent removal of preview builds of Java 6 for Mac, Apple has just as quietly released Java SE 6 Developer Preview 8, the first developer preview of Java 6 that runs on Leopard.

Many developers had feared that the removal of the previous preview signalled an intent from Apple to ignore Java 6 in favour of continued minor tweaks to Java 5. It seems now that the optimists were right: Apple just needed more time to get Java 6 right, so it took a step back and made some improvements to Java 5 for the Leopard release before pressing on with its work on Java 6.

The fact remains that if Apple were only to communicate with its closest allies—software developers—in a meaningful way, we wouldn’t be left playing these guessing games over the company’s intentions.

Missing in Action: Java 6 for Mac

Kevin Yank — Fri, 09 Nov 2007 00:47:44 +0000

Java developers are up in arms over the recent release of Mac OS X Leopard, and the sudden silence from Apple regarding the future of Java 6 on the Mac. Not only did Leopard not ship with Java 6, but Apple has quietly taken down the developer preview of Java 6, and is reportedly deleting threads in the Apple developer forums asking why.

As anyone who has attended a developer conference in the past few years can attest, developers as a group are some of Apple’s best customers. If only Apple treated its developers with as much reverence.

In a post on The Java Lobby entitled So Long Apple. The Party’s Over, Michael Urban summed up the situation nicely:

Not only did Leopard not ship with Java 6, but Apple, in typical fashion, apparently thinks it has no obligation to its customers to inform them about why the plans changed, and when (or even if at this point?) Apple will ever have a working copy of Java 6.

Now, it’s obvious that Apple hasn’t dropped Java completely. As many developers have pointed out, Apple did do plenty of work on its version of Java 5 for the Leopard release. Ben Galbraith recently gave a run-down of his favourite Java improvements in Leopard, based on Apple’s Release Notes for Java 5 on Leopard, for example.

But still, despite what is now going on two weeks of furor in the Java community, there is no word from Apple about the state of Java 6 on Mac OS X.

On the one hand, there is speculation that its release is imminent, based on Apple’s history of releasing Java 5 within weeks of Mac OS X Tiger. On the other hand, the significant improvements Apple made to Java 5 for the release of Leopard cast doubt in my mind over whether Apple has done any work on Java 6 lately.

None of this would be anywhere near as frustrating if Apple would simply break its stony silence. It’s one thing to hold back announcements of new products to maximize their marketing impact, but keeping your most important allies—developers—in the dark about the future of major technologies like Java is no way to do business.

First Look: Google Web Toolkit

Kevin Yank — Thu, 25 May 2006 01:29:42 +0000

Portions of this entry were first published in the SitePoint Tech Times #139.

Have you written your own AJAX framework yet? It seems all the big boys are doing it. Microsoft is bringing us Atlas for ASP.NET, Yahoo!’s User Interface Library is open source, server agnostic and beautifully documented and Adobe is working on Spry, which is off to a shaky start in the web standards department. Do we really need another?

Google’s late-but-inevitable entry into this arena is certainly no copycat. The Google Web Toolkit (GWT) is nothing less than a completely original approach to web development that allows server-side Java developers to take their skills to the JavaScript domain… without having to write any JavaScript.

In short, you write, test and debug your client-side code in Java and then use a specialized compiler to convert it all into cross-browser JavaScript for use on your site.

How’s it work?

You can write you client-side code using the usual core Java classes in the java.lang and java.util packages, as well as a nice library of classes that come with GWT that let you access the same browser features that are available in JavaScript (the Docment Object Model, alert boxes, setTimeout, XMLHttpRequest, etc.).

You also get a bunch of Java classes for adding widgets to the page, from simple buttons to complex drop-down menus and trees. All of these widgets offer events that you can subscribe listener objects to, and write Java code to respond to them.

When you’re ready to test out your application in a browser, you simply compile your classes in your Java IDE of choice and launch the GWT Shell, which pops up a specialized browser window and loads your application. On Windows, that browser window uses the Internet Explorer rendering engine, whereas on Linux it uses Mozilla.

The GWT Shell acts as a go-between between your Java classes and the special browser window, allowing your application’s client-side logic to run within the browser even though it is implemented in Java, not JavaScript. This small miracle actually lets you test and debug your client-side logic as you would any other Java code! Set breakpoints to pause and step through client-side event handlers, write unit tests to verify that your user interface works as designed. It all just works.

At this stage, your application is still a collection Java classes, and the final development step is to compile those classes down to efficient cross-browser JavaScript code. The compiler that comes with GWT actually reads the source code of your classes and generates the equivalent JavaScript code!

You can then take the generated JavaScript code, along with your static HTML, CSS and image files and dump them on a server as you would for any other web site. The resulting code is entirely self-contained — no browser plugins or special server technology required.

What about AJAX?

As I mentioned, the class library does give you access to the XMLHttpRequest object normally used in AJAX applications, but GWT also offers an even slicker method of communicating with the server.

In addition to your client-side code, you can write Java server-side code. Because it doesn’t get converted to JavaScript, this code can use the full capabilities of the Java platform, and any additional class libraries you may require.

In your client-side code, you can set up classes that are able to communicate with your server-side code. When your application is compiled, GWT will automatically generate all the JavaScript needed to communicate with the server on the client-side, and will compile your server-side code to a set of Java Servlets.

You can deploy these Servlets on any Java web server, and let GWT do the rest. GWT manages the conversion between JavaScript variables on the client-side and Java objects on the server side, and again it all just works.

GWT also includes a full browser history management system, allowing you to involve the browser’s Back and Forward buttons in your application’s navigation, even though the browser never actually leaves the page containing your applications.

Sticking Points

Google has definitely put together an impressive platform with GWT, but as one would expect (especially from a beta product) it’s not perfect:

GWT detects and supports browsers by their user agent string.
You must rely on Google to add support for future browsers. Right now, for example, GWT applications are incompatible with IE7. You can hack the toolkit to treat it like IE6, but that’s the extent of what you can do to support new browsers.
The bundled GWT widgets make extensive use of tables for layout.
If you want you application to generate a standards-compliant document structure, you’ll need to write your own widgets, which isn’t a happy prospect.
GWT was written to work with Java 1.4 or later.
As such, it does not take advantage of Java 5 features like annotations and generics. This adds some redundancy and bulk to the code you must write, especially when working with the AJAX features of the library. For example, each server-side access point in your application requires you to write an interface to describe the servce, another interface to describe the asynchronous version of the service, and finally a class to implement the service. Using annotations, you could do it all by writing just one class.
The development shell does not support Mac OS X.
Google is saying that Mac support is planned, but for now GWT development is limited to Windows and Linux. Compiled GWT applications run just fine in Mac browsers, of course.
Unclear best practices for security and performance.
By masking the client-server division, GWT could lead unwary developers to make some serious security and performance blunders. You really need to know what you’re doing to use GWT effectively.

But the biggest thing lacking in GWT is an example of a finished, real-world application running in the wild. No doubt Google is hard at work on its next big project using GWT, but for now at least GWT is unproven technology.

Write Java Web Apps in Visual Basic (or JavaScript!)

Kevin Yank — Fri, 19 May 2006 05:35:48 +0000

Sun: Open source Java not whether but how

Kevin Yank — Thu, 18 May 2006 08:28:41 +0000

Sun has conceded: Java will be open sourced.

During his opening keynote at JavaOne 2006, newly annointed Sun CEO Jonathan Schwartz welcomed to the stage Rich Green, Executive VP of Software, with the hard question: “Are you going to open source Java?”

After a little mock evasiveness, Green explained Sun’s latest thinking on the matter, ending with the bottom line: “It isn’t a question of whether, but a question of how. And so we’ll go do this.”

Green did take the time to point out that, from the perspective of community involvement and contribution to the development of the Java platform, Java is already effectively open source:

There’s two battling forces here. There’s the desire to completely open this up–complete access–I mean, so many changes of the licenses have been made that it’s virtually all there. But there is the sense of wanting to complete the program. The flip side is compatibility really matters. I don’t think anybody wants to see a diverging Java platform. One of the great values of Java has been that we’ve been able to keep it together–something you can all rely on in terms of its consistency and value and evolution. And the challenge, going forward, is how to solve for both of those things.

C|Net has video of the conversation, and of course the full webcast of the session is available on the JavaOne web site.

Follow JavaOne 2006 online

Kevin Yank — Thu, 18 May 2006 07:51:29 +0000

If you enjoy working in Java like I do, there are probably few places you would rather be right now than at JavaOne 2006. Particularly hot web development topics at JavaOne this year include the newly-released JavaEE 5 platform for building enterprise Java applications more easily, and the associated updates coming in NetBeans 5.5.

But whether due to time, money or geography, not everyone can make it to San Francisco to bask in the Java love for a week.

Thankfully, you can follow the big picture from wherever you happen to be. All of the general sessions (i.e. keynote speakers and demos) are available for viewing via live and on-demand webcasts that are almost as good as being there (plus you get to skip the boring bits!).

As for the more focused technical sessions, most of them have published downloadable PDFs containing the slides for free download from the session catalog. You can also wait until the dust settles and the slides will be freely available with synchronized audio from JavaOne Online.

And if podcasts are your thing, PodTech.net is hosting a series of podcasts from JavaOne, including the full audio of all the general sessions. Unfortunately, there is no dedicated feeed for just the JavaOne programs, so you might find yourself downloading some programs from other tech conferences going on at the same time.

JRun 5 hits beta

Kevin Yank — Mon, 01 May 2006 23:22:42 +0000

Adobe (formerly Macromedia) JRun 4 was released in 2002. Since then, Java web development has moved on somewhat. JRun 4 supports Servlet 2.3 and JSP 1.2, while most servers are now on Servlet 2.4 and JSP 2.0. At four years since the last release, many developers assumed development of the server had ceased.

But now it looks like JRun might be set to rise from the ashes, with Adobe looking for beta testers of a major new release. At this stage, Adobe is tight-lipped on what new features will come with this version–EJB 3.0? Jetty-like continuations? More affordable pricing?

I’ve asked for a look at the beta, and will report what I can when I can.

Tomcat sucks… Is Apache flawed?

Kevin Yank — Fri, 21 Apr 2006 05:26:21 +0000

High on my list of Java blogs is Hani Suleiman’s The BileBlog, in which he gives unapologetically abrasive reviews of popular Java projects and the people behind them. In the past, he has had been less than complimentary of the Apache Project‘s various open source (“opensores”) Java offerings like Maven and Struts. Today, he took Tomcat to task.

Tomcat, of course, provides the reference implementations for the Servlet and JSP specifications, but by virtue of the fact that it is free, it’s also the server of choice for many small-to-medium businesses. I took a critical look at Tomcat myself awhile back, while looking for a beginner-friendly Java web application server (I’m still looking).

Suleiman’s critique of Tomcat is based, somewhat refreshingly (he often resorts to unpersuasive, if entertaining, personal attacks on the developers), on the quality of the project’s code–or rather its lack thereof. Choosing a pivotal but relatively uncomplicated class (DefaultServlet, which is responsible for serving static resources like HTML/CSS/JavaScript files and images), he points out many examples of terrible coding practice, of which these are only a sampling:

Initialization code that lazily catches Throwable

        // Set our properties from the initialization parameters
        String value = null;
        try {
            value = getServletConfig().getInitParameter("debug");
            debug = Integer.parseInt(value);
        } catch (Throwable t) {
            ;
        }
        try {
            value = getServletConfig().getInitParameter("input");
            input = Integer.parseInt(value);
        } catch (Throwable t) {
            ;
        }

Throwable is the base interface for all Java exceptions an errors, many of which have no business being caught by this sort of code, let alone being ignored as this code will do. If the server happens to run out of memory while initializing a DefaultServlet, for example, this code will ignore the resulting error and attempt to continue running.

Attempts to identify particular exceptions by portions of their message strings

        try {
            serveResource(request, response, true);
        } catch( IOException ex ) {
            // we probably have this check somewhere else too.
            if( ex.getMessage() != null
                && ex.getMessage().indexOf("Broken pipe") >= 0 ) {
                // ignore it.
            }
            throw ex;
        }

Fortunately, the if statement in question (which, from the comment, it seems the developer was rather uncertain about) doesn't actually cause the exceptions it identifies to be ignored (as the second comment says it should do), so this confusing twist of poor programming is actually useless anyway.

A method that returns an exception instead of throwing it

    protected IOException copyRange(InputStream istream,
                                  ServletOutputStream ostream) {
        // Copy the input stream to the output stream
        IOException exception = null;
        ...
            try {
                ...
            } catch (IOException e) {
                exception = e;
                ...
            }
        ...
        return exception;
    }

As a believer in open source development, I looked at every issue he pointed out to give it the benefit of the doubt. "Okay, it looks silly, but there must be a good reason that they did that." There wasn't, of course, unless you consider laziness or ignorance a good reason.

For a project produced under the public scrutiny of the open source development, these are disturbingly fundamental issues indeed. For me, the most important question becomes not whether or not Tomcat sucks, but whether this level of code quality is the exception or the norm in the Apache camp.

I know for a fact that there is plenty of good quality open source Java code in the wild. I've probed into the code of Jetty a number of times, for instance, and have been pleasantly surprised by what I found there. I also know that poor open source code isn't just a problem that faced by Java. But Apache is supposed to be a leader in the field.

If the repeated condemnations of The BileBlog are any indication, the majority of the web could be running software like this--code that looks like it was written in a desperate push to meet a deadline with something that works... most of the time... just barely.

Sun Developer Days 2006: Day Two

Kevin Yank — Sun, 09 Apr 2006 21:14:12 +0000

The second day of Sun’s Developer Days 2006 conference in Melbourne last week was a similar mixed bag to the first. Be sure to read my coverage of day one if you missed it.

Before the day’s sessions began in earnest, Sun organiser David Coldrick got up to plug two useful resources for Java developers to keep up with the latest developments between Developer Days conferences: The Java Posse podcast (which I highly recommend as well!), and javapassion.com, which I have covered in this blog before.

Building Great Games for the Mobile World, Chuk Munn Lee (Sun)

Having done some work on mobile games already, I was hoping for some insight into the technical issues that face game developers on this platform: device-specific API fragmentation, application size and processing speed limits, inconsistent control methods, and more. What we got instead was a non-technical overview about the pros and cons of developing games for mobile handsets as compared to the PC- and console-based game platforms.

In brief, Java Micro Edition (ME) is a lightweight platform that can let you produce a fully-realized game for millions of potential users with as little as one man-month of development time. Successful games for this platform should take into account the fact that gamers will be playing on-the-go, for brief periods, and may stop playing at any time. Given this, the popular practice of adapting old games from other platforms to handsets is not a great approach.

Optimizing Performance for Java SE & Java EE Applications, Simon Ritter (Sun)

Again, my expectations were a bit off the mark for this session (I really wish the conference programme had included session abstracts). Rather than a grab bag of useful techniques for writing speedier code, or an overview of certain common performance anti-patterns, what we got was a tutorial on tuning the garbage collection algorithms in the Sun Java Virtual Machine (VM) using a variety of undocumented (or poorly documented) command-line switches.

I quite enjoyed the explanation of the VM’s heap management techniques, and how they allow for the tendency of Java applications to make extensive use of short-lived objects that must be garbage collected quickly and efficiently for Java to work, as well as the look at the biased locking algorithm that was introduced to further improve performance in version 1.5.0_06 of the Java 5 runtime. But the vast majority of the performance tweaks discussed would apply really only to high-load, multi-processor servers, so were little more than technical curiosities for me.

SOA, JBI, BPEL: Strategy, Design & Best Practices, Rima Patel (Sun)

In his day one session, Ashwin Rao showed off some of the tools Sun is cooking up for developers to tackle the unique challenges of building applications based on discrete, specialized services — a practice known as Service Oriented Architecture (SOA). Ms. Patel took a step back with this session and looked at the motivations and technical challenges of SOA, which must be considered long before development tools come into the picture.

While developers are used to facing new accronyms and buzzwords that, once grasped, bring technical benefits including performance, usability, and ease of development, SOA is very different, in that the motivations that drive it are largely business-centric.

Many big businesses today are straining under the weight of overlapping legacy systems that have been developed and connected on an ad hoc basis, on conflicting, often vendor-specific platforms. The SOA approach to this problem is to identify key services that exist within these systems and to either reimplement them or wrap the existing systems in interfaces such that applications can discover and access them openly, asychronously, statefully and securely through the exchange of XML documents that mirror the business documents that would change hands in the paper-based equivalents to the relevant business processes.

Ms. Patel went on to briefly outline the Java Business Integration (JBI) specification, which provides the plumbing for SOA applications in the form of an open framework that is both vendor and platform neutral. Not a bad option if you’re rearchitecting the IT systems for a major bank, which I’m not. For me, this session was mainly about confirming that my vision of what SOA means roughly matches with Sun’s. I make no guarantees as to whether or not it matches yours.

Java SE: Tiger, Mustang and Dolphin, Simon Ritter (Sun)

A relatively straightforward session, this talk rattled through an overview of the most high-profile features coming in Java 6 (codenamed Mustang) later this year. There’s plenty of good coverage of this going around, especially because Sun has been very open about Mustang’s development, with weekly builds available for download and testing.

Changes most likely to affect web developers in Java 6 are: full support for XML web services built in, the inclusion of the Rhino scripting engine, which will permit JavaScript code to run on the Java VM and make full use of Java class libraries; JDBC 4.0, which will simplify and enhance the primary API for Java applications connecting to databases; and better debugging support, making it easier to detect and diagnose deadlocks, memory leaks, and other runtime issues.

Personally, I’m most excited about the enhancements for desktop-based Java applications, but Mr. Ritter skipped over most of these in favour of more core changes to the platform.

Mr. Ritter did take a few minutes to give some hand-wavy examples of the sorts of things planned for Java 7 (codenamed Dolphin), including support for XML code appearing natively within Java code, and bytecode changes to support dynamic languages (such as scripting languages) running on the Java VM, but with almost nothing set in stone for Dolphin, every scrap of information was accompanied by the disclaimer: “On the other hand, we might not do this at all.”

Making AJAX more effective with servlets, JavaServer Pages Technology, & JavaServer Faces Technology, Doris Chen (Sun)

The confused title should have scared me off, but I went along to this session hoping at least to see some elegant examples of supporting AJAX applications within server-side Java code. I gave up and left after watching roughly 45 minutes of the speaker’s confused and confusing attempts to simply define what AJAX was. I wasn’t the only one to walk out.

I hate to pan the presenter further, but it’s a sad day indeed when you can’t keep a room full of developers interested in a presentation about AJAX.

Sun Developer Days 2006: Day One

Kevin Yank — Wed, 05 Apr 2006 11:08:20 +0000

Sun Microsystems is winding up a tour of Australia and New Zealand with the final stop of its Sun Developer Days 2006 conference today and tomorrow in Melbourne. Fellow SitePointer Lachlan Donald and I were there today to take in the Java vibes, and as with most free conferences there was a great deal of variation in the quality of the sessions we attended.

Sun Developer Tools, Bob Brewin (Sun)

In his keynote, Mr. Brewin spoke chiefly about the push Sun is making towards Ease of Development (EoD) across the entire Java platform and the set of Sun developer tools. Key examples of this included the new language features in Java SE 5.0, the release as a free download of Java Studio Creator, and the Java Persistence API, which is set to replace entity beans in EJB 3.0. This is all old news, however, and Brewin looked like he’d delivered this keynote fifty times before. Though some of the improvements being made to the Java landscape may be inspiring, this session was not.

Changing the Landscape of Software Development, Simon Ritter (Sun)

Mr. Ritter’s keynote essentially covered all of the ways Sun is fostering open source development with Java. Again, there was very little in this talk that would have been news to the people in the room, and Ritter seemed vaguely embarassed by this fact (even wondering aloud at some of the choices of imagery “his boss” had made in assembling his slides for him). The end of the session, which described all the ways in which Java was as good as, if not actually open source, seemed downright defensive… which was especially odd because a quick poll of the audience indicated only a small minority thought that it should be.

Rapid Web Application Development Using Sun Java Studio Creator, Ashwin Rao (Sun)

Very much a quick introduction, this session took a quick spin through Java Studio Creator, a tool for drag-and-drop web application development using JavaServer Faces (JSF). I’ve seen a couple of introductions like this in the past, and while I applaud what Sun has achieved with Creator in terms of making it possible to throw together Java web applications in a hurry, I’m still not sold on its merit for producing best practice code (at least, not out of the box).

Much like Microsoft’s Visual Web Developer edition of Visual Studio (with which Creator was obviously designed to compete), Creator lets you quickly produce web user interfaces by dragging ready-made components onto a design view. I shudder every time I consider the accessibility repercussions of using this development mechanism naively (particularly in the default “grid” layout mode, which makes use of absolute pixel coordinates to position all page elements).

That said, the JSF technology that Creator is based on is certainly capable of producing standards compliant, accessible web sites. What I want to know is whether the quick-and-dirty results that Creator seems so ready to produce are the fault of the tool (in which case I humbly suggest Sun should go back to the drawing board), the bundled components (in which case a dedicated group of developers could produce a more “responsible” set of components to use in Creator), or just the way the developer chooses to use them (in which case SitePoint should probably write a book similar to its recent Dreamweaver title).

SAP Technical Session: Running Open Source based Java EE Applications on the SAP Web AS, Taib Lokman (SAP)

While I’ve certainly seen the name SAP bandied about, I didn’t really understand how it fit into the Java space. It turns out that SAP has been in the Java enterprise development business for awhile, and today it offers its own suite of Java EE servers and Eclipse-based development tools. SAP sponsored the conference, so I was expecting a sales pitch in this session. What I got instead was unexpected, and very confusing.

In his talk, Mr. Lokman introduced and even demonstrated a number of popular open source Java enterprise technologies (Struts, Axis, Ant, etc.), seemingly held them up as great things that we should all be using, and then explained that SAP had its own more or less proprietary alternative that you would have to deal with if you were ever called upon to work on a project that relied on SAP’s platform. And that was it. Seriously, it was like “Who uses Struts? Great! Isn’t it cool? But if you use SAP, you’ll need to learn NetWeaver, which is quite different, instead.” Rinse and repeat.

Persistence for Java SE & Java EE, Rima Patel (Sun)

As the co-author of the bookMastering EJB, 3rd Ed. (free PDF download), which apparently has a 4th edition coming out soon that will also be freely available for download, Ms. Patel really knows her stuff when it comes to Enterprise JavaBeans (EJB). That translated to a dynamic and illuminating talk about what we can expect from the soon-to-be-released EJB 3.0.

The single biggest change to EJB 3.0 is the radical rethinking and simplification of entity beans. Used to represent database records (and other persistent data items) as Java objects that can participate in transactions and have their state synchronized with the database, entity beans have been a serious pain point in EJB for a long time. They require developers to write a lot of repetitive boilerplate code, and were limited in many ways that Java objects normally aren’t. In EJB 3.0, entity beans have been scrapped in favour of the Java Persistence API, which lets you use label plain old Java objects (POJOs) as entities, which can do all the things entity beans could do, but without all the tedious coding overhead and without all the limitations of entity beans.

For awhile now, Java developers have had the benefits of a lot of the Java Persistence API in the form of Hibernate, an open source library that maps relational database records to Java objects. With the Java Persistence API, however, those powerful capabilities will not only become a standard part of the Java EE platform, but they will be able work within EJB architectures, with all the resource and transaction management that EJBs were designed to provide.

Tackling Complexity & Improving Productivity in Developing to SOA, Ashwin Rao (Sun)

I haven’t had much to do with Service Oriented Architecture (SOA), an emerging vision of enterprise development where discrete, specialized services can be assembled and orchestrated together to produce useful applications with high degrees of scalability and flexibility. It’s certainly the direction that large enterprises are moving in, but at ground level where most of the developers in our audience reside, it’s not much of a factor. This session was an opportunity to check in with the state of SOA.

Mr. Rao briefly outlined the realities of SOA today, and then concluded that managing the resulting complexity means coming up with tools that address the unique challenges of orchestrating disparate services in a useful way. This offered a convenient lead-in to a demo of Java Studio Enterprise 8‘s UML modeling features, and the visual designer for Business Process Execution Language (BPEL) that Sun recently debuted in a preview of the Netbeans 5.5 Enterprise Pack.

The BPEL designer lets you assemble multiple web services together to produce composite services, essentially by drawing a flowchart to generate an XML description of the required process behind the scenes. Although the flowcharts produced by the tool were undeniably slick, whenever we glanced that the generated XML code it seemed to me that we could have written that code in much less time than it took to step through the wizards required to produce it graphically. Assuming SOA takes off and composite services will begin to involve more complex interactions than the simple demo we saw, I could see the value in being able to visualize those interactions rather than slogging through XML code; nevertheless, I was left with the impression that the problems of SOA that need to be solved are still being discovered, and as a result the tools are at least a generation away from becoming truly useful in the wild.

NetBeans Extreme: Matisse, Collaboration, Profiling and Plug-ins, Angela Caicedo (Sun)

In this marathon 90-minute session, Ms. Caicedo demonstrated just about every aspect of NetBeans 5.0, the latest version of Sun’s free Java IDE, that has been enhanced in this latest release.

NetBeans 5.0 caused a splash in the desktop application space by introducing Matisse, a remarkable new GUI layout tool that removes a lot of the complexity that Java developers have come to accept from the Java’s Swing GUI API without sacrificing much (if any) flexibility or quality in the finished product. Instead of relying upon Swing’s existing LayoutManager classes (such as the infamous GridBagLayout), Matisse uses its own GroupLayout class, which has since been slated for inclusion in the upcoming Java SE 6.0. The demo of Matisse in this session was enticing, if not entirely convincing to a veteran GridBagLayout user like me. It may be miles and miles ahead of any visual GUI layout tool Java has had in the past, but the demo suffered from a couple of minor layout issues that I could have avoided with GridBagLayout, and I’m curious if Matisse offers a solution to these.

The collaboration features were certainly a surprise — I’m not sure how I missed their mentions in the excitement surrounding NetBeans 5.0′s release. Similar features formed the major enhancements in JBuilder 2006 last year, but with the future of that IDE in serious jeopardy, it’s nice to see these features a healthy IDE like NetBeans. Essentially, the IDE includes an instant messaging client that allows you not only to chat to your fellow developers, but also to share your local project code, browse and edit that code collaboratively through shared views, and even run shared debugging sessions to locate problems together. I had assumed that, for this to work, both developers would need to have their own copy of the project in question on their system, but the demo showcased the fact that shared coding sessions are actually centered around one developer’s copy of the project, and all the other developers need is a copy of NetBeans to participate.

Next up, Caicedo took the profiling features in NetBeans for a spin, pinpointing the thread responsible for hanging the interface of a simple Swing application, and then identifying a slow method in a web application. The new profiler is one of NetBeans’s biggest advantages over the other, more popular free Java IDE, Eclipse, which lacks built-in profiling. While not quite as powerful as a dedicated profiling product like YourKit Java Profiler, the tools in NetBeans 5.0 are certainly respectable, and will assist in resolving all but the twistiest of performance issues.

Last, but not least, we got to watch a complete plug-in for the NetBeans IDE come to life before our eyes. With Java development spanning so many different application domains, it’s impossible for a single IDE to bundle every tool that a given developer might need. That’s why all the big IDEs these days place a great deal of emphasis on extensability through plug-in architectures. NetBeans is no exception, and with the integrated wizards and packaging tools Caicedo was able to add a Google search field to the NetBeans toolbar in mere minutes. IDE plug-in development, at least for NetBeans, is certainly a far less intimidating discipline than I had previously imagined.

So will I be switching to NetBeans tomorrow? I’m afraid not. Although NetBeans 5.0 has made some impressive strides, and the new pieces in the tool are certainly impressive, many of the basic facilities still have a “toy IDE” feel that I just can’t get past. Lack of fundamental facilities like multiple run configurations and project groups just don’t quite cut it for me. Still, there’s a lot to like in new features and old (I especially appreciate the use of Ant for all build tasks), so I’ll certainly be keeping an eye on NetBeans.

All up, after a weak start, the day got a great deal more interesting as talk turned from general spin to down-and-dirty coding. Hopefully tomorrow will hold more of the same!

JBuilder Seeks Good Home

Kevin Yank — Fri, 10 Feb 2006 02:57:36 +0000

Across the web, headlines are proclaiming the demise of JBuilder, the venerable Java IDE from Borland.

The truth of the matter, as always, is not so clear cut. Borland has announced that it’s looking to sell off its IDE business, including all the developers and staff responsible for producing and selling JBuilder, as well as Delphi, C++Builder, C#Builder and others. The announcement has a number of encouraging quotes by the company’s chief product evangelist about the products’ bright future in the “new company.”

When such a company will eventuate, and whether or not it will have the budget and drive to keep JBuilder in the competitive Java IDE game (currently dominated by Eclipse and NetBeans, with IDEA a trendy contender), remains to be seen.

As a longtime JBuilder user, I always enjoyed the product’s rich feature set. It always seemed like if it was worth doing, JBuilder could do it. It wouldn’t always be easy or attractive, but you could do it. Borland recently released JBuilder 2006, the twelfth major release of the IDE, where the major changes (aside from supporting new standards and technologies) were in the area of team development: with the new version, two developers can work together on a piece of code, each from his or her own desktop. The IDE provides tools for the developers to chat and give/take control over a shared code view.

But as JBuilder has evolved over the past few years, I’ve observed more and more focus on producing new “peripheral” features like these, while the core experience of day-to-day coding has remained relatively unchanged. As its innovative competitors have deployed rich coding assistance tools (such as static analysis of source code in IDEA and continuous integration in Eclipse), JBuilder’s efforts in these areas have seemed unpolished in some cases.

Several months ago, I took the plunge and switched to IntelliJ IDEA, which offers free licenses to developers who work on open source products like I do. Although there were a few features I missed from JBuilder (such as support for JAR archive signing in the build process), the overall environment and workflow just felt more polished, and more carefully thought out, while JBuilder always felt like just a dazzling collection of features.

Up until this announcement, the next step in JBuilder’s evolution was to be its reincarnation on the Eclipse platform, codenamed Peloton, with some of the base components to be open sourced. The rights to this in-development product will go to whichever company buys Borland’s IDE business, but until that happens, and the new company announces its intentions, it’s safe to say that JBuilder’s future — in any form — is in definite jeopardy.

Step-by-Step Jakarta Tapestry

Alexander Kolesnikov — Wed, 01 Feb 2006 14:00:00 +0000

The Jakarta Tapestry framework is a hidden treasure of Java web development. It greatly simplifies the work of both web designers and developers. It offers significant convenience by transparently handling much of the boring "plumbing". It even changes the paradigm of web development (at least in terms of the presentation tier) to one that is more natural.

Yet Tapestry remains more or less unknown to a great majority of web developers, for numerous reasons. The most obvious is Tapestry’s legendary "steep learning curve" which, in my opinion, is more myth than reality: Tapestry is in fact easier to learn and use than are many other frameworks. Yes, internally Tapestry is more complex than its predecessors, in the same way that a contemporary camcorder is much more complex than those mechanical devices that our grandfathers used to produce their amateur movies. But is a camcorder more difficult to use? No, it is much, much easier (believe me — I’ve tried both types of devices).

All right, enough brainwashing, let’s jump straight in! By the end of this tutorial, you’ll be able to decide for yourself just how easy Tapestry is to use. We won’t be creating the traditional ‘Hello World’ web application here — that really would be too trivial with Tapestry. We’ll start with something more realistic: a login form.

On our way to unraveling the wonders of Tapestry, we need to pass through a kind of purgatory — the process of creating of a working, Tapestry-ready configuration on our computers. This is more or less standard practice for Java web development, so we’ll make it as simple as possible.

If you’ve ever tried any kind of Java Web development — using servlets, JSP or Struts — chances are that you’ll already have most of the necessary components on your machine. But if not, don’t worry: we’ll install everything very quickly and easily. In fact, the installation is mostly about downloading and unpacking ready-to-use pieces of software.

Requirements

We’ll need the following:

Java Development Kit (JDK)
Tomcat Web server
Eclipse Integrated Development Environment (IDE)
Spindle plugin for Eclipse IDE
Tapestry-specific libraries

If you already have some of these components installed on your computer, just skip the appropriate part of the instructions that follow.

Although Tapestry 4 has just been released, we’ll start from the third version of the framework. Many concepts of Tapestry development are more or less the same in both versions — especially from a beginner’s viewpoint. Additionally, Spindle, a very convenient and helpful tool for Tapestry development, is currently only available for Tapestry 3.

What we are going to do now may not seem very exciting, but we need to do this just once. Some of the following instructions are platform-specific — choose whichever are appropriate for you.

Installing the JDK

If you’ve ever tried your hand at Java development, you’ll already have a JDK installed on your computer. It comes pre-installed with the latest versions of Mac OS X. To verify whether you have it or not, try the following.

In Windows, choose Start > Run…, then type cmd and press the OK button. In Linux or Mac OS X, simply open a terminal window.

Enter the following command at the prompt:

javac

Press Enter. If your computer has a JDK installed and configured, you will see more than a dozen lines of output, beginning with the following:

Usage: javac   

where possible options include: 

  -g                        Generate all debugging info 

... more lines of output ...

If your computer didn’t recognize the command, you’ll need to install a JDK. You could install either the latest version, JDK 5.0, or the previous one, JDK 1.4.2. Both are fine for the purposes of this tutorial. Let’s assume that you’re going to install the most recent version.

1. Download the JDK

For Windows and Linux: download the recent version of JDK 5.0 (at the time of writing, it’s JDK 5.0 Update 6). Please note: you will need the JDK, not the JRE!

Some advice for Linux users: whichever distribution you use, you might wish to download the Linux self-extracting file (jdk-1_5_0_06-linux-i586.bin), not the Linux RPM self-extracting file (jdk-1_5_0_06-linux-i586-rpm.bin). In some cases, the former is easier to install and configure.

For Mac OS X: You may not need to download anything, as you probably already have something like the JDK 1.4.2_09 installed on your computer. If you want the new version of the JDK, download it here. However, be warned that changing the default version of the JDK in Mac OS X is not a trivial task, so for the purposes of this tutorial, you might want to stick to the pre-installed JDK 1.4.2.

To better understand the problems running Java 5 on Mac OS X, refer to this discussion at the Javaranch.com forum.

2. Install the JDK

With Windows and Mac OS X versions, you aren’t given many choices; just launch the executable file you’ve downloaded, and follow the instructions.

In Linux, you’ll need to change permissions for the downloaded file in order to be able to execute it:

chmod +x jdk-1_5_0_06-linux-i586-rpm.bin

Then, execute it:

./jdk-1_5_0_06-linux-i586-rpm.bin

Once you agree to the terms and conditions that are shown to you, the file will unpack itself. Move the resulting directory, jdk1.5.0_06, to the location where you want it to live (e.g. to /usr/java).

Now, you need to add the bin subdirectory (say, /usr/java/jdk1.5.0_06/bin) to the PATH of your machine. One way you can accomplish this under Linux is to add the following two lines to your .bashrc file (if you use bash, of course):

PATH=/usr/java/jdk1.5.0_06/bin:$PATH 

export PATH

That’s it! If you followed these instructions correctly, you should have the JDK installed.

Installing Tomcat

Strictly speaking, Tomcat is much more than a web server — it’s what’s referred to as a servlet container, which works as a gateway between the world of Web and the world of Java. But it has a decent web server in it too, at least for development purposes. Installing Tomcat is very easy, but we do need to configure an environment variable afterwards.

1. Download Tomcat

This step is common for all the platforms, as Tomcat is a Java program! Go to http://tomcat.apache.org. If you’ve got JDK 5, choose the latest stable version of Tomcat (at the time of writing, this is 5.5.12), otherwise download Tomcat 5.0.28 — for our purposes it will work exactly the same.

2. Unpack Tomcat

Unpack the downloaded package into a directory of your choice. This might be c:\apache-tomcat-5.5.12 on a Windows computer, something like /home/alex/apache-tomcat-5.5.12 under Linux, or /Users/alex/jakarta-tomcat-5.5.12 under Mac OS X. The installer wizard for Windows makes this process even easier.

3. Set the JAVA_HOME Environment Variable

This environment variable should point to the directory into which you’ve placed your JDK. Since we’re dealing with the computer’s operating system at this point, the following instructions are platform-specific.

Windows XP

Your JDK may have been installed automatically, but it’s not difficult to find out where it was installed. It most probably lives in the C:\Program Files\Java directory, so your environment variable should point to something like this:

C:\Program Files\Java\jdk1.5.0_06

To set the variable, right-click on My Computer and select Properties. In the dialog that opens, choose the Advanced tab, then click the Environment Variables button at the bottom.

The System Variables are listed in the lower portion of the window (see Fig. 1). If you don’t see JAVA_HOME there, create it by pressing the New button, otherwise edit it as needed by pressing the Edit button.

Fig.1. Setting JAVA_HOME in Windows XP

Linux

If you installed the JDK as described above, you’ll know where it is. Otherwise, you might need to find it using the following command:

which java

This will display something similar to this:

/usr/java/jdk1.5.0_06/bin/java

Your JAVA_HOME should therefore point to /usr/java/jdk1.5.0_06.

There are several places where you can set an environment variable in Linux. My preferred option is to edit the .bashrc file, adding the following line:

export JAVA_HOME=/usr/java/jdk1.5.0_06

Mac OS X

The Mac OSX process is mostly the same as the one we used for Linux, the difference being that finding the location at which your JDK is installed is more difficult on Mac. To find out, type:

which java

This will give you something like:

/usr/bin/java

In this case, your JAVA_HOME should point to /usr.

To set the variable, edit your .bash_profile file and add to it the following line:

export JAVA_HOME=/usr

4. Test it!

To test whether or not your installation of Tomcat really works, go to the bin subdirectory of the directory where you installed Tomcat. In other words, if you’ve installed Tomcat into c:\apache-tomcat-5.5.12, go to c:\apache-tomcat-5.5.12\bin.

There, you’ll find the following scripts: startup.sh and shutdown.sh (for Linux and MacOS X usage) and startup.bat and shutdown.bat (for Windows).

Note that on a Linux or Mac OS X machine you may need to change the permissions of all the .sh scripts in this directory in order to be able to execute them, but that’s easy:

chmod +x *.sh

To start Tomcat, launch startup.sh or startup.bat (depending on your platform), wait a few seconds, then navigate your web browser to http://localhost:8080. If everything’s functioning correctly, you’ll see a page similar to Fig.2.

Fig.2. If you see this page, your Tomcat was installed successfully.

In the world of networking, localhost refers to your own computer, when it’s referred to as a server. When you navigate to localhost:8080, you are actually asking your computer if anybody is listening on port 8080 (ports on your computer are like telephone extensions inside your office). And this is where Tomcat is listening, by default, so it shows its face.

To stop Tomcat when you don’t need it any more, use the shutdown.sh or shutdown.bat scripts. If you used the Windows Tomcat installer, you’ll also have a handy little monitoring tool that sits in your task bar. You can use this to start and stop the server.

Installing Eclipse

An efficient and convenient IDE greatly enhances a developer’s productivity, and when it comes to Tapestry development, the natural choice of IDE is Eclipse, primarily because the Spindle plug-in we’re going to use only exists for Eclipse, but also, of course, because the Eclipse is a superb IDE!
Installing Eclipse is very simple. Go to the Eclipse downloads page and download the version that suits you, for example eclipse-SDK-3.1.1-win32.zip for Windows, eclipse-SDK-3.1.1-macosx-carbon.tar.gz for Mac OS X, or eclipse-SDK-3.1.1-linux-gtk.tar.gz for Linux. Unpack the download to the directory of your choice, e.g. c:\eclipse or /Users/alex/eclipse.

You can start the IDE by launching Eclipse.app in Mac OS X, eclipse.exe in Windows, or by typing eclipse in Linux. When you start Eclipse for the first time, you’ll be asked to choose your workspace — the directory in which all your Eclipse projects will be stored. You can choose either the default directory, or a different one.

That’s it! Now we’ve got the JDK, Tomcat and Eclipse, all of which are prerequisites for general Java Web development. Now, we’re going to enrich our work environment with a few Tapestry-specific components.

Installing Spindle

This Eclipse plug-in greatly simplifies Tapestry development, and it’s quite easy to install.

Open your Eclipse IDE. Choose Help > Software Updates > Find and Install…

Figure 3. Selecting to install Spindle

In the dialog that appears, select Search for new features to install and press Next. In the next window, press the New Remote Site… button. Enter Spindle for the Name and http://spindle.sf.net/updates for the URL, then press OK and Finish. You will be prompted to select a mirror; select the closest location to you and press OK.

Eclipse will search for the plug-in and show you the result, as shown in Figure 3 above. Select Spindle and press Next.

In the next dialog, accept the terms in the license agreement and press Next. Finally, press Finish. Eclipse will download everything it needs to install Spindle (this could take half an hour or more, depending on your connection). It will then ask you to verify that you really want to install ‘an unsigned feature’ (see Fig.4).

Choose Install All and, when the installation completes, agree to restart your workbench.

Great! Now your IDE is ready for Tapestry development. The very last step we need to take is to download all the libraries that Tomcat needs to run a Tapestry Web application, and place them in an appropriate location.

Figure 4. Installing Spindle: Verification Stage.

Downloading Tapestry and Other Libraries

Tapestry 3 itself comes in two .jar files: tapestry-3.0.3.jar and tapestry-contrib-3.0.3.jar. But it also relies on other libraries, some of which are included in its distribution, while others need to be downloaded separately. The easiest way to get all the necessary libraries is to download the tapestry_libs.zip archive that I have created for you.
Unpack all the contents of this archive into the shared/lib directory under your Tomcat installation. It can be, say, c:\apache-tomcat-5.5.12\shared\lib on a Windows machine or /Users/alex/jakarta-tomcat-5.5.12/shared/lib on Mac OS X.

Whew, we’ve done it! We’re now ready to unleash the magic of Tapestry.

Our First Tapestry Web Application

First, let’s visualize what we’re going to create. Our first Tapestry application will be quite simple — though still useful — and will have two pages. The first page will display a login form: just a standard form that ask for a username and a password. The second page will greet visitors using their login names — that is, if they successfully pass authentication. If the login/password combination is wrong, the login page will be redisplayed again.

Figure 5 shows what both pages should look like when completed. For simplicity, I haven’t used any styles here, but you can apply your creativity to create a design of your own.

Figure 5. This is how the completed pages of our application will look.

In fact, it makes sense to begin the development of your Tapestry application by first creating the HTML ‘mockups’ — prototypes of your future pages that show exactly how they’ll look in a working application.

You can exercise all your creative skills to the full when creating mockups or, if you’re the manager or client of a good design team, tell your designers not to limit their imagination. You’re not going to spoil their efforts by inserting ugly tags or mixing carefully crafted design with an unintelligible mix of HTML and code. As you’ll soon see, Tapestry treats page design with great care.

Here’s the HTML code for my page mockups:

Page 1:
"http://www.w3.org/TR/html4/strict.dtd"> Welcome to Tapestry!

`Welcome to Tapestry!`

  
    
    User Name: 
  
        Password:

Page 2:
"http://www.w3.org/TR/html4/strict.dtd"> You've got it!

`Precious User!`

  
  Welcome to the wonderful World of Tapestry!

Now that we have our mockups ready, let's create our first Tapestry project.

Creating a Tapestry Project

Fire up Eclipse (but not Tomcat yet). To create a new Tapestry project, choose File > New > Other... and, under the Tapestry node, choose Tapestry Web project, as shown in Fig. 6. Then press Next.

Figure 6. Choosing a Tapestry Web Project

Name the project, say, 'Login', and check the box Include the Tapestry redirect filter in web.xml (see Fig.7).

Fig. 7. Naming the project

Press Next, and in the next window click Finish. You'll see the structure of your new application, as shown in Fig.8.

General Structure of a Java Web Application

Fig. 8. The Structure of a New Tapestry Project

If you don't have any experience with Java web development, you might benefit from a brief overview of the standard structure of Java web application. This structure is common to all frameworks based on servlets, including JSP, Struts, Tapestry and virtually everything that exists in the Java web world.

A simplified version of this structure is shown in Fig. 9. The whole application is contained within one directory, which is given the name of the application. We've labeled this top-level directory AppName in the diagram.

Fig. 9. The Generic Structure of a Java Web Application

Directly under AppName live those resources that are directly accessible by the outside world, via the Web. This includes HTML pages, JSP pages, CSS files, images and any other resources that might be needed for the external part of the application. I use the term "external" because if you have, say, a page named MyPage.html that's stored directly under the AppName directory on your www.myserver.com server, web users can see that page by pointing their browsers to http://www.myserver.com/AppName/MyPage.html.

Images and style sheets are often put into a subdirectory -- in this case, one named assets. Grouping content like this helps to keep things neat; this subdirectory will be also accessible to everyone.

You'll notice a (particularly important) subdirectory named WEB-INF. It should be named exactly like this -- not web-inf or Web-Inf -- otherwise your Web application won't work. This is the inner sanctum of a Java Web application: nothing that goes inside this directory will be exposed directly to the outer world (i.e. to the Web).

There's an important file inside WEB-INF named web.xml. It has the same name in all Java web applications, and is the deployment descriptor. The purpose of this file is to tell Tomcat some general, important information about the application.

There are also two subdirectories under WEB-INF, named classes and lib. All the compiled Java classes that make up the application go into the classes subdirectory, and all the libraries that are used by the application go into the lib directory -- simple! Many other files serving different purposes can be kept under WEB-INF and in its subdirectories, but this is the standard structure.

Now, let's see how this arrangement maps to the structure of our first Tapestry application, created for us by Eclipse (together with Spindle).

The Structure of our Web Application

You can see that the top level directory of our application is named Login -- the name that we gave to the application.

The src subdirectory was created for our convenience. This is where the source code of all our Java classes will be stored. Below it, you'll see two library references: Tapestry Framework and JRE System Library. Eclipse displays them here to indicate that we have them at our disposal for this project. There's also a context subdirectory. All of our application's files -- everything that was listed directly under AppName in Figure 9 -- are stored in the context subdirectory. We don't have any static HTML pages here right now, but we might do later. We would also keep any images or style sheets here if we had them. Right now, we see just the sacred WEB-INF file.

In WEB-INF you'll see the deployment descriptor, web.xml. We won't explore it just yet, though.

We haven't created any Java classes, nor have we used any libraries, so no classes or lib subdirectories are displayed just yet.

There is also a Login.application file that contains application-wide configuration. Right now, we'll just leave it as it is, but later, when we make some changes to it, we'll discuss the contents of this file.

Now we come to the most interesting part of the process: creating Tapestry pages.

Creating the Home Page

You'll notice that Spindle has created two more files for us: Home.html and Home.page. A page named Home is the default page for a Tapestry application, very much like index.html is the default page for a Website's directory. If no page is specified in a request from the client, Tapestry will show the Home page.

We'll put our login form on this page. Let's see what sort of HTML Spindle has created for us. Double-click the Home.html file to open it in the editor:

This is just an empty stub for a HTML page. Let's replace it with our mockup for the first page. We'll add a doctype, a title and a simple form to the body.


    "http://www.w3.org/TR/html4/strict.dtd">  

  

  

  Welcome to Tapestry!  

  

  

  Welcome to Tapestry!
  

    

    User Name: 
  

        Password:

Let's say we've just received this carefully crafted HTML page from our design team. It's time to apply our knowledge of Tapestry and convert the mockup into the real thing -- an HTML template for a Tapestry page! Here's the end result of such a conversion:


    "http://www.w3.org/TR/html4/strict.dtd">  

  

  

  Welcome to Tapestry!  

  

  

  Welcome to Tapestry!
  

    

    User Name: 
  

        Password:

Of course, your eagle eye has spotted the changes we've made, but will your web browser notice them? Open the original mockup in a browser of your choice, then open the converted version and check if there are any differences. There aren't. Because those strange jwcid attributes mean nothing to a web browser from a rendering perspective, it just ignores them.

You might be interested to know that jwcid means "Java Web Component ID", and these jwcid attributes are our way of telling Tapestry, "We want to apply some magic here. Please turn these standard HTML elements into dynamic Tapestry components." As a result, the standard HTML element

will become a Tapestry component, as will the two standard elements.

By the way, the names that you assign to jwcid attributes are, more or less, arbitrary. If you like, you can give them name them like jwcid="bilbo" or jwcid="FrodoBaggins". But don't try something like jwcid="%@^&*", the language of Mordor won't work here. I recommend you use something indicative of the type of data the file represents.

Fig. 10. Spindle Has Found an Error

All right, so if the component IDs are arbitrary, how will Tapestry know exactly which of its standard or custom components you want to use in place of the static HTML? You might notice that Spindle isn't quite happy with our new attributes -- it underlines the first of them with a red line and draws a red, crossed circle in the left margin of the editor window (see Figure 10). If you hover your cursor over the underlined word or the red circle, you'll see this error message:

Tag  on line 7 references unknown component id 'loginForm'.

Logically, there should be a place where we can specify for Tapestry the details of our design, and there is! This place is called the page specification and for our Home page it is represented by the Home.page file, which was already created for us by Spindle.

Now is the time to discuss the following revelation: Tapestry pages actually consist of three parts:

an HTML template (Home.html for our first page, for example)

a page specification (such as Home.page)

a page class (we'll call ours Home.class -- see later)

The HTML template defines what our users will see. The page class contains the page's functionality. And the page specification links the components in the template with the corresponding functionality in the page class. It specifies all the necessary details for these components, and may also contain some other page-specific information.

We'll return to the three-part nature of Tapestry pages later -- and more than once, too -- because it's very important. But right now, let's create the page specification for our Home page. Double-click the Home.page file in your Package Explorer in Eclipse. This is what you should see:

  


  "-//Apache Software Foundation//Tapestry Specification 3.0//EN"  

  "http://jakarta.apache.org/tapestry/dtd/Tapestry_3_0.dtd">  

  

  

  

  add a description

If you don't have much experience with XML documents and doctypes, don't pay too much attention to the first five lines. The first line just states that this is an XML document. The cryptic-looking tag tells an XML parser how to understand the document that follows.

We're interested in the information inside the page-specification element, beginning with the attribute class="org.apache.tapestry.html.BasePage".

Remember how I told you that every Tapestry page consists of three parts, one of which is a Java class that contains the page's functionality? Even if you don't create a class, a default class exists anyway -- the BasePage class referred to by this attribute. Of course, it doesn't contain any custom functionality, but it still has many default methods that give us access to the infrastructure of Tapestry.

When we decide to create our custom page class, it will always extend this default BasePage class.

Next comes the description element. You can either leave this as it is, or if you are like me and prefer to keep your stuff well organized, go ahead and add a description of the page -- something like 'Login page'.

Inside of the page-specification element, we have to explain to Tapestry what we really meant when we wrote jwcid="uname" etc.

Here, I'll show you what we're going to write for our page specification, and explain what it means before we type it into Eclipse. In a moment you'll see how we can use some handy features of Spindle and Eclipse to write all these specifications in no time at all.

First, we're going to describe our loginForm component. Its specification will look like this:

You may already have deduced that this piece of XML tells Tapestry: "The jwcid="loginForm" that I inserted into the HTML template will be a standard Tapestry Form component."

The binding element actually creates a link between the HTML template and the page class. When the name of the binding is listener (there are a few other names available), we're describing the name of the method on the page class that will be invoked when the form is submitted.

A Tapestry Form's listener is specified like this:

The only part of this element that you can change is the actual listener method name, in this case onFormSubmit. You have control over the name of this method, so you could call it onSubmit, or something that was more meaningful to you, if you liked. Let's stick with onFormSubmit for now; Tapestry will therefore be looking in the page class for a method with the following signature:

public void onFormSubmit(IRequestCycle cycle) {}

It will be your responsibility to provide the implementation of such a method. And if you decide to name the listener myGloriousMethod, make sure that you provide a method to Tapestry with the signature:

public void myGloriousMethod(IRequestCycle cycle) {}.

Where can you provide such a custom listener method? In a custom page class (we'll come to that later). Don't bother for now about that IRequestCycle thing, either -- we'll come to that in a moment. Right now, let's tell Tapestry how to handle the other two components that we're yet to specify.

The first is uname, for storing the user name. This is how it should be specified:

Here, we're telling Tapestry that what we marked in the HTML template as jwcid="uname" is actually a standard Tapestry TextField component, and the value obtained from it should be stored in a property uname. Again, this will be a property of our custom page class, but we'll cover that later. You can actually name this property whatever you like, though it is convenient (and good practice) to give the property the same name as the component's ID.

The last component on our Home page is password. This is how it should be specified:

This tells Tapestry that the component we marked as password is also a TextField, that its value should be stored in a property named password, and that its hidden parameter should be set to true.

Because Tapestry doesn't have a special Password component, the effect of replacing keystrokes with asterisks is achieved by setting the hidden property of a normal TextField component to true, so that the characters are not echoed to the screen.

The difference between and is that is evaluated by Tapestry every time the form is rendered or submitted, which is good for unpredictable or variable values (who knows what password a user will enter?). On the other hand, is good for constant values: we want the hidden parameter always to be true; this will be remembered by Tapestry, which won't evaluate hidden every time, saving precious resources.

Now let's edit our Home.page file and add to it the component specifications we've just discussed. But writing XML by hand is boring and error-prone, so we're going to rely on Spindle's help here.

Place your cursor in the line below the tag and press Ctrl + Space. In the Code Assist window that opens, select component (see Fig. 11).

Fig. 11. Writing component specification with the help of Code Assist

Press Enter and you'll get a stub of a component specification:

Notice that value is already selected for you, so you can enter something to replace it immediately. Enter loginForm. Press Tab, and the cursor will jump to the next place of entry. This feature may not work if you're constantly switching between your browser and your Eclipse window, so you might want to print this tutorial or arrange your workspace (or, if possible, memorize these few steps) so you can perform this procedure in one go. Press Ctrl + Space again, select type from the list and press Enter. This is how your new specification should look:

The word value is selected again. Once again, press Ctrl + Space and type the letter 'f'. You'll see the names of the components that start with F. Choose Form and press Enter. This is what you'll see now:

Press Tab again to jump to the next entry point, right between the and tags, and -- you guessed it -- press Ctrl + Space. Choose binding (empty) from the list and press Enter. At this stage, your specification will look like this (I pressed Enter another couple of times to format the code nicely; you might want to do the same):

With the word value selected, press Ctrl + Space. Choose listener, press Enter, then Tab and Ctrl + Space again. The only choice in the list will be expression, so choose it by pressing Enter. Finally, enter listeners.onFormSubmit instead of value. That's it! We've completed the specification for our first component.

After you become accustomed to using Code Assist, you'll see how easy it is to write component specifications.

Now go on and have some practice. Create specifications for the other two components, and check back here when you're done. The final result of your numerous Ctrl + Space keystrokes should look like this:

   


  "-//Apache Software Foundation//Tapestry Specification 3.0//EN"   

  "http://jakarta.apache.org/tapestry/dtd/Tapestry_3_0.dtd">   

   

   

   

   

  Login page   

       

     

    
        expression="listeners.onFormSubmit"/>

We've completed the page specification for our Home page, and the Spindle syntax checker should be completely happy with what we have written (i.e. there should be no wavy red lines either in Home.html, nor in Home.page). However, the page won't work yet. Remember, we promised Tapestry that there would be an onFormSubmit listener and two properties named uname and password in the page class.

Right now, this page uses the default BasePage class, and it doesn't have any custom methods or properties. To implement our custom logic, we should create our own Java class that will inherit from BasePage.

Creating the Page Class

Right-click (or Ctrl-click on a Mac) in your Package Explorer and choose New > Other..., then, in the Select a wizard dialog, choose Class (see Fig. 12). Press Next.

Figure 12. Selecting a Class wizard

In the Java Class dialog enter a package name, for example com.sitepoint.tapestry.login. Enter Home for the name of the new class, and org.apache.tapestry.html.BasePage for the Superclass. Make sure the public static void main(String[] args) checkbox is deselected -- we're not going to run this class as a standalone program. You might find it useful to add automatically generated comments, so select the Generate Comments checkbox. The final result should look like Fig. 13.

Figure 13. A new class is ready to be created

Press Finish, and a brand new page class will be generated for you in a few seconds. It will be named Home.java and its code will look like this:

/**   

 *    

 */   

package com.sitepoint.tapestry.login;   

   

import org.apache.tapestry.html.BasePage;   

   

/**   

 * @author alex   

 *   

 */   

public class Home extends BasePage {   

   

}

This is where we define our listener method. Specify it like this:

public class Home extends BasePage {   

   

  public void onFormSubmit(IRequestCycle cycle) {   

    // Some code will go here   

  }   

}

At this stage, we'll create only the skeleton of the method -- the rest of the code will be added later. The mysterious IRequestCycle parameter can be thought of as Tapestry's representative in our code. Whenever we need something from the framework, we'll ask this cycle to get it for us. We'll see an example of this soon.

However, at the moment Eclipse tells us that it doesn't know what an IRequestCycle is. To make it happy, we'll need to add the following import statement:

import org.apache.tapestry.IRequestCycle;

Now that we have a custom page class, we need to specify it in our page specification. Change the opening tag in Home.page to look like this:

Specifying Properties the Tapestry Way

Now is the time to deal with the two properties uname and password. There are two ways to specify a property in Tapestry: the standard Java way (a private class member, public getter and setter, and perhaps some other maintenance code), and the Tapestry way. The latter, although it looks slightly unusual, is used much more often, so we'll use the Tapestry approach here.

We don't want to write all that property-related code by hand, so we'll just ask Tapestry to generate it for us automatically at run time. All we need to do is to describe how the properties should be named, and what type they should be (any Java class available to Tapestry can suffice as the type).

You've probably already guessed that we'll describe the properties we want in our page specification. In Home.page class, just below the tag, add the following two lines (of course, you don't have to write them all out by hand -- use your Code Assist Ctrl + Space skills):

That's it! Now you can just assume that at run time these properties will be ready for you, and they'll be managed by Tapestry properly without any efforts from your side and without any code written by you.

Previously, before we even specified these properties, we had already connected them to two of our components: a TextField component with the ID uname is bound to the property uname, and a TextField component with the ID password is bound to the password property. Let me describe all the activities that Tapestry will perform based on our page specification:

When the Home page is requested, Tapestry will create the page class for it (an instance of com.sitepoint.tapestry.login.Home, created by us). It will then notice that we asked to add two properties to this page, so Tapestry will create an 'enhanced' version of our class (i.e. another class that inherits from Home), and will add to it the two requested properties along with all the code that might be needed to handle them.

Tapestry then asks the enhanced page class instance to render itself to the user. To do that, the page class instance will use our Home.html template. When rendering the uname and password components, the class instance will check whether these components have any default values. We didn't specify any, so the components will just be shown as blank text fields.

When the login form is submitted, Tapestry (using the same kind of page class instance, either created anew or taken from the pool) will take the values entered by the user into the two text fields, and put them into their corresponding properties, so that we can use them in our code.

It took three paragraphs for me to describe what Tapestry will do automatically for us as a result of just a few lines in the page specification. You don't really need to know all those procedures when you're taking your first steps with Tapestry. All you need to know is that you can specify the properties you need, connect them to the components you use on your page and, as a result, whatever is submitted by a user will be available in your code via these properties.

The only nuance is that to use or edit a value of this kind of property in your code, you should create a getter or a setter (or both, if necessary) in your page class. Admittedly, this is a tad unusual: you didn't create any properties in your Java code, and you certainly didn't write anything like this:

private String uname;   

private String password;

Yet we're asking Tapestry to provide them at run time, so we'll just believe that the properties will be there. All this is a little bit... abstract. And yes, we are going to create abstract getters for these shadowy properties. Here they are:

public abstract String getUname();   

public abstract String getPassword();

We'll add these getters to our page class and, since it will have abstract methods, this class will also become abstract! This is how it will look (with comments removed for the sake of brevity):

package com.sitepoint.tapestry.login;   

   

import org.apache.tapestry.html.BasePage;   

import org.apache.tapestry.IRequestCycle;   

   

public abstract class Home extends BasePage {   

  public void onFormSubmit(IRequestCycle cycle) {   

    // Some code using getUname() and getPassword will go here   

  }   

     

  public abstract String getUname();   

  public abstract String getPassword();   

}

Using abstract classes as a "final product" in your application looks somewhat strange, but as soon as you get used to it, you'll realize that this is actually very handy: you write exactly what you need, and Tapestry takes over and cleverly creates all the "plumbing" for you.

By the way, you can see this approach not only in Tapestry, but also in EJBs with container-managed persistence.

Right, we've written enough to test our first Tapestry page. It won't do anything visible at this point, but at least we can check whether Tapestry understands our code properly. If everything goes as planned, we'll see a web page that looks identical to our mockup for the Home page.

Informing Tomcat about our Web Application

Before running our Tapestry Web application for the first time, we need to inform Tomcat that we've created this application and where to find it. To do this, we'll create a very simple XML file, a kind of note for Tomcat. We'll call it Login.xml. You can use any text editor to create this file; it won't be a part of our Web application.

This is all we need to write:


    path="/Login"/>

In the docBase attribute, you must specify the path to the context subdirectory of your Web application. It will depend on where you've chosen to place your workspace directory when installing Eclipse. In this example, you can see the location of this directory on my Mac. It will be something similar on a Linux machine.

For Windows, note that when specifying the path to your context, you should use forward slashes, not the backward ones normally used in Windows paths. In other words, you should write docBase="c:/workspace/Login/context", instead of docBase="c:\workspace\Login\context".

Put this Login.xml file into the conf/Catalina/localhost subdirectory in your Tomcat directory (examples: c:\apache-tomcat-5.5.12\conf\Catalina\localhost or /Users/alex/jakarta-tomcat-5.0.28/conf/Catalina/localhost).

We're now ready to run our Tapestry Web application.

Running the Application

Start your Tomcat server as explained in the "Installing Tomcat" section. If Tomcat was already running, shut it down and start up again -- this will give Tomcat the opportunity to read the new configuration file that we just created when it starts up.

Point your browser to http://localhost:8080/Login/app. If everything was done properly, you should see the login page as shown in Figure 5 -- exactly as expected. If instead you get an error, go back and double-check that every step has been followed, then restart your Tomcat server and try again.

You already know that a request for http://localhost:8080 will invoke Tomcat running on your computer. /Login tells Tomcat which Web application we want our request sent to. Remember, when configuring Tomcat in the previous section, we told it the path to our application using path="/Login".

The /app part of our request tells our application that this is a request for its Tapestry part. By default, it's configured in such a way that all requests addressed to Tapestry must end with /app. This is for the case that our application contains other, non-Tapestry resources -- static HTML pages, for example. In the next part of this tutorial, I'll show you how to change the configuration so that all requests to /Login are passed to Tapestry.

Congratulations! You've got your first Tapestry Web application running. Admittedly, it's not much more impressive than 'Hello World' right now, but behind the scenes this page is already using three Tapestry components, and it's just waiting for us to add more functionality.

Let's add the following ground-breaking behaviour: when a user presses the "Let me in!" button, the second page will be displayed. For now, we won't perform any validation of the username or password. We'll just react to the pressing of the button by displaying the second page.

Which second page? The one we are going to create right now!

Creating the Second Page

Let's name the second page Content, as though it contained something valuable requiring user authentication.

Right-click the Package Explorer, choose New > Other... , and locate and select the Tapestry Page option. Press Next.

In the New Tapestry Page Component dialog which opens, enter Content for the Page Name. Make sure that the Generate an associated HTML file? checkbox is checked. Leave all other values to their default settings and press Next.

Here you can choose which class to use as a page class. We're going to create some custom functionality, so let's make our own class. Select the Create a new class radio button. Specify the package to be com.sitepoint.tapestry.login, and make the class public and abstract (yes, we are going to use those shadowy Tapestry properties again). Your dialog should look like Figure 14.

Figure 14. Creating a New Page with a Custom Page Class

Press Finish and Spindle will create three new files for you: Content.html, Content.page and Content.java.

The default HTML template for the second page doesn't contain anything useful, so we'll replace its contents with the mockup code from Page 2 in the previous section (titled "Our First Tapestry Web Application"). Modify this mockup into the real HTML template, which looks like this:


    "http://www.w3.org/TR/html4/strict.dtd">    

    

    

  You've got it!    

    

    

  Precious User!
    

  Welcome to the wonderful World of Tapestry!

You can see that, on the second page, we'll be using just one Tapestry component, which is named uname and disguised as a standard HTML span element. You're probably aware that the span element is often used to apply a special style to text. We won't be specifying any styles here, just our magical jwcid, which is incomprehensible and invisible to a web browser.

A Specification for the Second Page

We're going to need both the username and password in the code for the second page, so let's create the same two properties in the page specification (you can just copy them from Home.page):

Let's also specify the uname component mentioned in the HTML template. This time, it will be a standard Tapestry Insert component, which simply inserts a string into the outputted HTML. This is how the specification will look:

And here's the completed page specification, which goes into the Content.page file:

    


  "-//Apache Software Foundation//Tapestry Specification 3.0//EN"    

  "http://jakarta.apache.org/tapestry/dtd/Tapestry_3_0.dtd">    

    

    

    

    

  Content page    

      

  
      type="java.lang.String"/>

All that's left is to fill in our custom page class with some functionality.

Adding Functionality to the Page Class

We want to be able not only to read the uname and password properties of the page, but to set them as well. That's why we'll create two pairs of abstract getters/setters for the page class. Remember from the first page that these methods will be abstract, because we didn't create the properties ourselves, but asked Tapestry to make them for us at run time.

With the addition of getters and setters, our Content.java will look like this:

package com.sitepoint.tapestry.login;    

    

import org.apache.tapestry.html.BasePage;    

    

public abstract class Content extends BasePage {    

  public abstract String getUname();    

  public abstract String getPassword();    

  public abstract void setUname(String uname);    

  public abstract void setPassword(String password);    

}

It's now time to return to the first page, Login, and add functionality to its page class so that when the form is submitted, the second page (that we named Content) is shown.

Navigating From Page to Page

Our listener method onFormSubmit() is still empty. Let's add some code to it to display the second page. This can be done quite simply: we'll just ask Tapestry to show another page.

How do we ask Tapestry to do something for us from our code? We've got its representative, cycle (of type IRequestCycle), which is passed as a parameter to our listener method. So let's just ask this cycle object to do the job for us. This is what our listener method in Home.java looks like:

public void onFormSubmit(IRequestCycle cycle) {    

  cycle.activate("Content");    

}

Let's see if it works. At the moment, we need to keep restarting Tomcat every time we make a change, in order to see the most recent version of our application. This is definitely not the most convenient thing to do, and there are easier ways to achieve the same result. However, we've had enough distractions already, so I'll leave you to research the alternatives. For the moment, let's press on.

Shut down Tomcat if it was running, then start it up again. Point your browser to http://localhost:8080/Login/app and you'll see our login form. Push the Let me in! button and you should see the second page as shown on Fig. 15.

Figure 15. The Second Page is Displayed Without a User Name

Notice that no username is output. Well, I didn't ask you to enter a login or password into the login form! But even if I had done so, we didn't tell the second page in our listener method what information we were receiving from the user. Let's correct this.

Passing Parameters to the Second Page

I'll now show you a design pattern that's used often in Tapestry development to pass variables to another page: the "bucket brigade" pattern.

We'll do the following:

Ask Tapestry to give us a reference to the next page that we want to display.

Use setters on that page to assign values that we want to pass to the page's properties.

Ask Tapestry to display the next page.

At this point you should understand one important thing: although the users of our web application think of the pages they're viewing as HTML that's being sent to their browsers, in reality (and as far as Tapestry is concerned), each page is a Java class -- a page class -- such as Home or Content. This class has many talents; the ability to send an HTML response is just one of them.

Our next page is called Content. So, if we wanted to declare a reference to the next page, it would look like this:

Content nextPage;

We can tell Tapestry: "Please give us a reference to an instance of a page class for the page named Conten&nt". Translated into Java, it would look like this:

Content nextPage = (Content) cycle.getPage("Content");

After receiving the reference, we can use it to invoke any setters that we have prepared in that next page. For example, if we had a username and password received from a user stored in uname and password variables, we could write this:

nextPage.setUname(uname);    

nextPage.setPassword(password);

We'll then ask Tapestry to show the next page:

cycle.activate(nextPage);

Our completed listener method looks like this:

public void onFormSubmit(IRequestCycle cycle) {    

  Content nextPage = (Content) cycle.getPage("Content");    

  nextPage.setUname(getUname());    

  nextPage.setPassword(getPassword());    

  cycle.activate(nextPage);    

}

Note that in nextPage.setUname(getUname()); we're calling the abstract getter of our Home class and passing the returned value to the abstract setter of Content class. It looks strange: how can we use a method that has yet to be implemented? But it works perfectly well at run time, because Tapestry creates implementations of all the abstract methods for us.

Let's test the new version of our application. Shut down and start up your Tomcat server, and point your browser to http://localhost:8080/Login/app. When the login form appears, enter a user name and any password into it and press the Let me in! button. Depending on which user name you used, the result might look like Figure 16.

Figure 16. The Second Page Displays as Expected

Limiting Access to a Page

Since we're requesting a user name and password, it would be natural to limit access to our valuable Content page, so that only authorised users can access it. For now, let's hard-code one password for all users.

Normally, we'd check the password in the Login page and, if it was correct, we'd send the visitor the hidden Content. But what if some unwanted visitor managed to request the Content page directly, without logging in? Technically, this is possible.

One of the solutions to this problem is to check the password in the Content page. If the password is correct, we display the contents of the page, otherwise we redirect the user to the Login page.

To be able to do this, our Content page needs to make an agreement with Tapestry. It should ask, "Please notify me when you are going to show me, so that I can check a few things." This kind of agreement can be achieved if the page implements the PageValidateListener interface. To implement this interface, we need to declare it and add a pageValidate() method to our page class. With these additions, our Content.java looks like this:

package com.sitepoint.tapestry.login;    

    

import org.apache.tapestry.html.BasePage;    

import org.apache.tapestry.event.PageValidateListener;    

import org.apache.tapestry.event.PageEvent;    

    

public abstract class Content extends BasePage     

    implements PageValidateListener {    

      

  public void pageValidate(PageEvent event) {    

    // Some code will go here    

  }    

      

  public abstract String getUname();    

  public abstract String getPassword();    

  public abstract void setUname(String uname);    

  public abstract void setPassword(String password);    

}

Notice the two new import statements. You don't have to know where to find the classes or interfaces that you need, and you don't need to write these statements by hand. Eclipse will do all that for you. For example, when you type PageEvent, Eclipse will underline it with red, because it doesn't know what you mean. Place your cursor somewhere on this word and choose Source > Add Import, and this smart IDE will create the necessary import statement for you!

Tapestry will check that the page implements the PageValidateListener interface, so it should have a pageValidate() method. Tapestry calls this method just before showing the page to a user, and it is up to us to define which checks should be done in the method.

We're going to check if the password specified by the user is the same as the one we've hard-coded. If not, we'll tell Tapestry: "Stop! Don't show this page! Redirect the user to the Home page instead." This is what it looks like in Java:

if (!"mellon".equals(getPassword())) {    

  throw new PageRedirectException("Home");    

}

If the password entered by the user is "mellon" (the Elvish word for "friend"), everything is fine: they'll see the Content page. If not, we switch on an alarm and tell Tapestry: "Forget whatever you were doing, just show our login form to this user."

This is how the completed Content.java should look:

package com.sitepoint.tapestry.login;    

    

import org.apache.tapestry.PageRedirectException;    

import org.apache.tapestry.html.BasePage;    

import org.apache.tapestry.event.PageValidateListener;    

import org.apache.tapestry.event.PageEvent;    

    

public abstract class Content extends BasePage implements PageValidateListener {    

      

  public void pageValidate(PageEvent event) {    

    if (!"mellon".equals(getPassword())) {    

      throw new PageRedirectException("Home");    

    }    

  }    

      

  public abstract String getUname();    

  public abstract String getPassword();    

  public abstract void setUname(String uname);    

  public abstract void setPassword(String password);    

    

}

Now let's test our completed login web application.

Start or restart Tomcat and navigate, as usual, to http://localhost:8080/Login/app. Enter any user name and a wrong password, and press the Let me in! button. Nothing should happen -- you'll just see the same login form. Now type the secret word for the password that we hard-coded above. You should be able to view the Content page!

What Have we Learnt?

First, we saw that Tapestry HTML templates can be displayed perfectly in any web browser, because Tapestry's server-side hooks are limited to the attributes of standard HTML tags, so they remain virtually invisible.

This is very important because the presentation (HTML) remains absolutely independent of the logic (Java code), and either of them can be edited without any changes to the other. This is the cleanest possible separation between presentation and logic -- something that other frameworks struggle with and often fail to achieve.

We also saw how convenient and useful the Eclipse IDE (with the Spindle plug-in) is when it comes to Tapestry development.

We got our hands dirty and created a couple of pages, and saw that every page has three parts to it: an HTML template, a page specification and a page class.

We learned that Tapestry components are declared in the page specification, and saw how the binding is established between a component's jwcid attribute in the HTML template and either an event listener or a property.

We also saw one of the trickier but more powerful aspects of Tapestry: how page properties can be declared in the page specification, and how we can work with them as if they really existed, even though they're only created by Tapestry at run time.

We learned how to write code to navigate from one page to another, and how to pass parameters between pages (the "bucket brigade" pattern).

Finally, we saw how a Tapestry page can protect itself from being accessed by unauthorised visitors, and how little needs to be done to implement this functionality.

Whew! We've mastered quite a lot for this introduction, but there is still much more to the world of Tapestry!

Further Reading

Currently there are only two books on Jakarta Tapestry available in English:

"Tapestry in Action" by Howard Lewis Ship, the creator of Tapestry. This book is useful for gaining a deeper understanding of the ideas behind Tapestry, and details of the inner workings of Tapestry 3. However, it's not very useful as a tutorial for beginners.

"Enjoying Web Development with Tapestry" by Ka lok 'Kent' Tong. I would call this book an advanced tutorial, and it is a must-have title for every Tapestry developer. It's packed with examples and advice starting from the basics and going on to some advanced topics. I found it invaluable when working on my own commercial Tapestry application. The book is available in two editions: for Tapestry 3 and for Tapestry 4.

Java Studio Creator 2 Released and Still Free

Kevin Yank — Thu, 02 Feb 2006 01:45:27 +0000

When I first announced that Sun was making its Java Studio Creator product available as a free download, some skeptics labelled this as a mere publicity stunt ahead of the release of Creator 2.

Well, Java Studio Creator 2 is now here, and it’s still free.

Java Studio Creator is based on JavaServer Faces (JSF) technology, a component-based approach to web development that is similar in style to ASP.NET. This positions Java Studio Creator as a direct competitor to Microsoft’s Visual Studio 2005 Express Editions. Both bring drag-and-drop rapid application development to the web and both are free downloads, but Creator is free of many of the restrictions placed on Microsoft’s Express Editions (e.g. it offers a full visual database query builder).

And of course, being written in Java, Creator will run on Mac OS X and Linux systems.

A brief overview of some of the new features:

improved code completion in code editors (Java, HTML, CSS)
a new graphical CSS editor
EJB Support (was beta in Creator 1)
many new JSF components
a new database support layer
HTTP monitoring
AJAX components (including a Google Maps component)
runs on Java 5 with associated speed and UI benefits

If you’ve considered Java web development in the past and were put off by code-heaviness and cryptic XML configuration files, you should definitely check out the video product tours for Creator 2 to see just how easy it can be.

All Java, No Froth: 6 Easy Steps to MVC Web Apps

Kevin Yank — Tue, 24 Jan 2006 14:00:00 +0000

It’s an exciting time to be a Java web developer. Gaining popularity amongst hosting providers, Java 5 (Java 2 Standard Edition 5.0) contains a pile of new language features to bamboozle complacent developers who had grown used to knowing the language inside and out. Hosts have also largely deployed the latest releases of major Java web application servers, which support the current standards in Java web development (J2EE 1.4). And the major development tools have been updated to support the powerful features of these standards, such as JavaServer Faces. It’s all right there, waiting for you to use it.

At the same time, Java is getting a bad reputation among everyday web developers. There’s a growing sense that Java isn’t easy anymore, that you have to work for a company with the budget equal to the GDP of a small country for web development on this platform to make sense. Competing platforms like Microsoft’s .NET are winning loads of cool points for doing things that Java has done for years; nimble scripting languages like Ruby are making amazing things possible with very little code, while Java is perceived as a stagnant monolith by many.

A lot of this sentiment comes from the fact that Java web development was invented in layers. First there was this great, easy-to-learn programming language: Java. Someone wanted to generate web pages with it on the fly, so servlets were invented, and they ran on Java. Someone else wanted to build dynamic web pages without losing the HTML code among all the Java code, so JavaServer Pages (JSP) were invented, and they ran on servlets, which ran on Java.

Years later, the cutting edge of Java web development sits on top of at least a half dozen layers of technology, and as a newcomer you can quickly feel lost in the forest of buzzwords! So now we get hobbyists asking how to build a web-based photo gallery with Enterprise JavaBeans (EJB) – the equivalent of buying a tractor trailer to carry your bread and milk home from the corner store.

In this article, I’ll chart a map through that forest of buzzwords, so that as you take your first steps in Java web development you can work out what you really need to know, what you can really use, and what you can safely leave to the multinationals. Most importantly, I’m here to express the joy I find in working with Java. I hope I can help you find it, too.

Let’s Start at the Bottom…

As I have mentioned, Java web technology has been built up in layers over many years. Today, there are at least a dozen practical and proven approaches to building web sites with Java. By and large, however, they are all built on the same foundation: Java Enterprise Edition (JavaEE) — previously Java 2 Enterprise Edition (J2EE) — a constellation of related specifications that describe the aforementioned layers of server-side Java technology.

Picking our way through J2EE, we’ll start by looking at Servlets, then we’ll move on to JSP, combine the two as we examine Model 2, extend this to a discussion of MVC frameworks like Struts and Spring, and evenutally explore the various View technologies like Velocity, JavaServer Faces, and XMLC. This is by no means an exhaustive list — there’s lots to explore!

GA_googleFillSlot(“Articles_6_300x250″);

As we do this, I predict you’ll notice an interesting trend. Most web development platforms start out being reasonably easy to learn and use, but they tend to get more and more complicated as you try to shoehorn larger, more practical and complex projects into them. PHP comes to mind: much as I love that language’s ease of use, you can spend months reading people’s thoughts on how best to structure sizeable projects and still not come up with a clean solution.

The trend with Java is different: there is a lot to learn up front, and at first simple tasks can seem stupidly labour-intensive. But as you become comfortable with the layers of complexity, they begin to work for you, and projects that you used to find intimidating will start to seem easy.

To begin our tour, we’ll start with a dead simple web application: a database driven to-do list. We’ll be building this same application with each of the technologies we explore, and I’ll provide downloadable code for each version. Because this is a simple project, it’ll allow you to focus on the differences between the techniques, their strenghts and weaknesses, which features are easy to implement, and which are hard.

Each incarnation of this application will rely on the same MySQL database, so let’s start with that. If you plan to follow along, now’s a good time to make sure you have a healthy MySQL installation on your development machine. If you’re really new to databases or server-side web development in general, you can find a solid introduction to MySQL with full installation instructions in the first two chapters of my book, Build Your Own Database Driven Website Using PHP & MySQL. These chapters are available as free articles on sitepoint.com: chapter one and chapter two.

With MySQL in place, create a new database (I’ll call it todo) with the following single table in it:

CREATE TABLE todo ( 

  todoid INT NOT NULL AUTO_INCREMENT PRIMARY KEY, 

  todo VARCHAR(255) NOT NULL 

)

That’s it! We’re all set to look at the Java classes that will interface with this simple database.

Talking to MySQL: Your First Look at JDBC

To build the to-do list application we will use to explore the myriad Java web development technologies that are available, we’ll begin with the backbone of the application: a set of classes that connect to a MySQL database to retrieve, model, and update a to-do list.

Before we go any further, you’ll need a working knowledge of Java as a programming language. At the very least, you should understand the basic concepts of object oriented programming: classes, objects, methods, properties, and constructors. For an overview of these concepts and the necessary basics of Java programming, see my articles: Getting Started with Java, Java Language Basics, and Object Oriented Concepts in Java (part one and two).

In the following discussion, I’ll also make use of many of the built-in utility classes that Java offers in its core APIs. If you’re curious about these (and you should be!), you can browse the reference in the Java 5 API documentation, or grab a copy for yourself from the same page where you downloaded JDK.

Since we’re connecting to a database, we will be using the Java Database Connectivity (JDBC) classes, which are part of the Java Enterprise Edition (JavaEE) platform, supported by all Java-enabled web servers. JDBC provides a common set of classes for connecting to any database server (you can browse the API reference for these classes if you like).

In order to connect to MySQL with JDBC, we need to grab a copy of MySQL Connector/J, the JDBC driver for MySQL. After telling Java to load the driver, we can ask it to connect to a MySQL database, and all of the standard JDBC classes will know how to work with that connection.

Download and extract the MySQL Connector/J archive. Inside you’ll find a mysql-connector-java-version-bin.jar file (version 3.1.12 as of this writing), which is the driver library. Ignore the rest of the fluff and copy the JAR file to the working directory in which you plan to build your to-do list Java application.

We’re ready to start coding! In this article, I’ll present all the code line-by-line, so that you can type it straight into your favourite text editor. If you’re used to some of the more terse scripting languages out there, Java code may seem a bit verbose to you. Indeed, that’s one of the main things people who don’t like Java tend to complain about. For real world development, I would highly suggest you get yourself a solid Integrated Development Environment (IDE), such as NetBeans or Eclipse (both are free). A good IDE will write much of the code for you, so that Java’s verbosity becomes an aid to code readability, not a hindrance to productivity. In these initial learning stages, however, typing all the code by hand will definitely help you absorb exactly what’s going on, so I’ll leave further exploration of IDEs for a later article.

First of all, let’s build a class called ToDoList, which will represent the to-do list stored in the database and will allow us to access and modify its entries. We’ll put this class in a Java package (or namespace) called com.sitepoint so, in your working directory, create a directory called com with a subdirectory called sitepoint, and in it create a file named ToDoList.java. Start the file out with the required package declaration:

package com.sitepoint;

In this class, we’ll use the JDBC classes from the java.sql and the collection classes from java.util, so let’s import those:

import java.util.*; 

import java.sql.*;

Finally, we’ll declare our class:

public class ToDoList {

To keep the class as database-independent as possible, we’ll design its constructor to accept the name of a JDBC driver and a JDBC connection string, which together give it everything it needs to connect to a database through JDBC. The constructor will load the driver class immediately, then store the JDBC connection string in a private property, so that the object can use it to connect to the database when it needs to.

  private String jdbcConnectionString; 

 

  public ToDoList(String jdbcDriver, String jdbcConnectionString) { 

    this.jdbcConnectionString = jdbcConnectionString; 

 

    // Load the driver 

    try { 

      Class.forName(jdbcDriver).newInstance(); 

    } 

    catch (Exception ex) { 

      System.err.println("Error loading database driver " + jdbcDriver + 

                         ":\n" + ex.getMessage()); 

    } 

  }

Class.forName() obtains a reference to the JDBC driver class, and calling its newInstance() method makes sure it is loaded. We catch any exceptions that may be thrown in case the driver class is not available (if you forget to do this, the compiler will remind you about it).

Now, our first version of this class will allow Java programs (and web pages) to:

Get a list of the items on the to-do list.
Get the number of items on the list.
Add new items to the list.
Delete items from the list.

Because fetching the list from the database can be a time consuming operation, we’ll make our class keep a copy of the list once it has been fetched, and only update it from the database when necessary.

  private List list = new ArrayList(); 

  private boolean staleList = true;

The list variable will store the list retrieved from the database, and the second will keep track of when that list needs updating (i.e. when it is "stale"). We start off with an empty ArrayList (Java’s stock-standard list class, from the java.util package), which is assumed to be in need of updating.

Now, whether the program wants the actual list of to-do items or it simply wants to know how many items there are, we will need to fetch the list from the database. So let’s write a single private method that checks if the stored list (in the list property) is stale, and loads the list from the database if necessary:

  private void refreshList() { 

    if (staleList) { 

      // Load list from the database... 

 

      staleList = false; 

    } 

  }

Loading the list from the database is where JDBC comes in. First, we use the JDBC connection string (stored by the constructor in jdbcConnectionString) to connect to the database. Since this is a time consuming operation, we’ll store the connection in another private property called conn, and only create a new connection when it is empty:

        if (conn == null) { 

          conn = DriverManager.getConnection(jdbcConnectionString); 

        }

Next, we create a Statement object from the connection and use it to execute a SELECT query and obtain the resulting ResultSet object:

        Statement stmt = conn.createStatement(); 

        ResultSet rs = stmt.executeQuery("SELECT todoid, todo FROM todo");

With the results in hand, we store a new, empty ArrayList in the list property, and fill it with ToDoItem objects created from the contents of the result set:

        list = new ArrayList(); 

        while (rs.next()) { 

          list.add(new ToDoItem(rs.getInt(1), rs.getString(2))); 

        }

This may be a confusing bit of code for several reasons. First, we’re using a while loop to step through the result set. Calling the next() method of the result set advances it to the next record, or returns false if there are no records remaining, thus ending the while loop.

Within the loop, we’re using the add() method of the ArrayList class to add items to the list. But what exactly are we adding? New instances of the ToDoItem class.

ToDoItem is a simple little class that keeps track of an ID (the database ID of a to-do list item) and a string (the text for that item). These two values are "read only", in that there are no methods provided for altering them. Objects like this that represent records in the database are called data objects. Create this class by pasting the following code into a file called ToDoItem.java alongside the ToDoList.java file you're already working on:

package com.sitepoint; 

 

public class ToDoItem { 

  private int id; 

  private String item; 

 

  ToDoItem(int id, String item) { 

    this.id = id; 

    this.item = item; 

  } 

 

  public int getId() { 

    return id; 

  } 

 

  public String getItem() { 

    return item; 

  } 

 

  public String toString() { 

    return getItem(); 

  } 

}

The only detail worthy of note in this simple class is that the constructor is not declared public, but is instead left package private, so that only classes within the com.sitepoint package can create ToDoItem objects.

Returning to ToDoList, the constructor of ToDoItem expects to be given the ID and text values for the item. We can fetch these values from the current row of the result set, using getInt(1) to fetch an integer value from the first column (todoid) and getString(2) to get a string value from the second column (todo).

That’s it for filling up the list, except that to handle database errors from all this we much catch any SQLExceptions that might be thrown (again, the compiler will remind you if you forget). Here’s the completed refreshList() method, and the delcaration for the conn property:

  private Connection conn; 

 

  private void refreshList() { 

    if (staleList) { 

      try { 

        if (conn == null) { 

          conn = DriverManager.getConnection(jdbcConnectionString); 

        } 

        Statement stmt = conn.createStatement(); 

        ResultSet rs = stmt.executeQuery("SELECT todoid, todo FROM todo"); 

 

        list = new ArrayList(); 

        while (rs.next()) { 

          list.add(new ToDoItem(rs.getInt(1), rs.getString(2))); 

        } 

      } 

      catch (SQLException ex) { 

        System.err.println( 

            "Error retrieving to-do list items from the database:\n" + 

            ex.getMessage()); 

      } 

      staleList = false; 

    } 

  }

With the hard work done in refreshList(), implementing getToDoItems() and getItemCount(), to obtain the to-do list items and the number of such items respectively, is a cinch:

  public Iterator getToDoItems() { 

    refreshList(); 

    return list.iterator(); 

  } 

 

  public int getItemCount() { 

    refreshList(); 

    return list.size(); 

  }

The iterator() method of Java’s list classes returns an Iterator, an object much like the database result set we just worked with, that lets the requesting object step through the list. size(), meanwhile, is self-explanatory.

The addItem() and deleteItem() methods work much the same way as refreshList(), except they use a PreparedStatement instead of a simple Statement. Consider this code from addItem:

      PreparedStatement stmt = conn.prepareStatement( 

          "INSERT INTO todo (todo) VALUES (?)"); 

      stmt.setString(1, item); 

      stmt.executeUpdate();

Notice the question mark in the INSERT query. This indicates a spot where some unknown value will be added to the query (the text for the new to-do list item, in this case). The setString(1, item) method call that follows assigns a string value (provided by the item variable in this case) to the first spot in the query. Other methods like setInt() let you enter values of other types. Sticking values into your database queries in this way neatly sidesteps the character escaping issues that often come into play with other languages, and that are often the cause of security vulnerabilities.

Here’s the complete code for addItem() and deleteItem(), thus completing our ToDoList class:

  public void addItem(String item) { 

    try { 

      if (conn == null) { 

        conn = DriverManager.getConnection(jdbcConnectionString); 

      } 

      PreparedStatement stmt = conn.prepareStatement( 

          "INSERT INTO todo (todo) VALUES (?)"); 

      stmt.setString(1, item); 

      stmt.executeUpdate(); 

    } 

    catch (SQLException ex) { 

      System.err.println( 

          "Error adding a to-do list item to the database:\n" + 

          ex.getMessage()); 

    } 

    staleList = true; 

  } 

 

  public void deleteItem(int id) { 

    try { 

      if (conn == null) { 

        conn = DriverManager.getConnection(jdbcConnectionString); 

      } 

      PreparedStatement stmt = conn.prepareStatement( 

          "DELETE FROM todo WHERE todoid=?"); 

      stmt.setInt(1, id); 

      stmt.executeUpdate(); 

    } 

    catch (SQLException ex) { 

      System.err.println( 

          "Error deleting a to-do list item from the database:\n" + 

          ex.getMessage()); 

    } 

    staleList = true; 

  }

Notice that each of these methods sets staleList to true once it’s done its job, so that the next attept to read the to-do list will cause refreshList to fetch it from the database again.

All we need now is a class to test the work we’ve done so far. Here’s a class called ToDoTest that’ll do the trick. Put ToDoTest.java in with your other files:

package com.sitepoint; 

 

import java.util.*; 

 

public class ToDoTest { 

  public static void main(String[] args) { 

    ToDoList list = new ToDoList("com.mysql.jdbc.Driver", 

        "jdbc:mysql://localhost/todo?user=root&password=password"); 

 

    System.out.println("The to-do list contains " + list.getItemCount() + 

                       "items:"); 

    Iterator it = list.getToDoItems(); 

    while (it.hasNext()) { 

      System.out.println(" - " + it.next()); 

    } 

 

    list.addItem("Another todo item."); 

    list.addItem("And yet another."); 

 

    System.out.println("The to-do list contains " + list.getItemCount() + 

                       " items:"); 

    it = list.getToDoItems(); 

    while (it.hasNext()) { 

      System.out.println(" - " + it.next()); 

    } 

  } 

}

You’ll need to substitute your MySQL database name, user name, and password into the JDBC connection string near the top of this file.

Compile your three classes from the top-level working directory:

javac com/sitepoint/ToDoList.java com/sitepoint/ToDoItem.java 

    com/sitepoint/ToDoTest.java

Then run ToDoTest, with the MySQL JDBC driver added to the classpath:

java -classpath .;mysql-connector-java-3.0.15-ga-bin.jar 

    com.sitepoint.ToDoTest

You should see a list of the to-do list items before and after the two new items are added to the list, something like this:

The to-do list contains 2 items: 

 - Another todo item. 

 - And yet another. 

The to-do list contains 4 items: 

 - Another todo item. 

 - And yet another. 

 - Another todo item. 

 - And yet another.

Download the source code. (5KB)

That’s it! We’re ready to build a web application around these classes.

Servlets

If you’ve followed along, you’ve now got a to-do list database and a couple of classes that view and update it. The next step is to take that functionality to the web by wrapping it in a web application. On the Java platform, there are dozens of ways to do this. The simplest approach is to write a servlet. A servlet is simply a class that has methods that handle requests from web browsers.

Basic page requests are handled by a doGet() method. Form submissions that use the POST method are handled by a doPost() method. Objects passed to these methods provide access to information about the browser request and allow control over the servlet’s response.

GA_googleFillSlot(“Articles_6_300x250″);

An XML configuration file controls the URLs the servlet is responsible for, and provides any configuration information that the servlet may require.

The Java web application standard (J2EE) even specifies a directory structure, so that the servlet always knows where to find any class files, configuration files, and additional web resources (like images and style sheets) that it needs.

Let’s start by putting the stuff we have already into the correct directory structure. Create a new empty directory to work in, then create a subdirectory called WEB-INF. All of the "normal" web resources (HTML pages, images, style sheets and JavaScript files) will go in the main directory, while all the Java stuff (classes, libraries and configuration files) will go in WEB-INF.

Within WEB-INF, create two more subdirectories: classes and lib. WEB-INF/classes will contain all the Java classes for our web application, and WEB-INF/lib will contain any libraries that those classes may require.

Speaking of required libraries, remember from the previous section that our ToDoList class requires the JDBC driver for MySQL (MySQL Connector/J) to access the database. For a standalone application, we needed to add the JAR file (mysql-connector-java-version-bin.jar) to the classpath. For a Java web application, simply drop the file into the WEB-INF/lib directory.

Since we’ll be using the classes we’ve already developed (ToDoList and ToDoItem) in our web application, we need to put them in the WEB-INF/classes directory. You might as well drop the source files in there along with the compiled classes, just in case you need to make any changes — recompiling will then be a breeze.

Here’s our file and directory structure so far:

/WEB-INF/classes/com/sitepoint/ToDoItem.class  

/WEB-INF/classes/com/sitepoint/ToDoItem.java  

/WEB-INF/classes/com/sitepoint/ToDoList.class  

/WEB-INF/classes/com/sitepoint/ToDoList.java  

/WEB-INF/lib/mysql-connector-java-version-bin.jar

Let’s now turn our attention to building the servlet for our application. Remember, servlets are just Java classes, and this one will be com.sitepoint.ToDoServlet:

package com.sitepoint;  

  

import java.io.*;  

import java.util.*;  

import javax.servlet.*;  

import javax.servlet.http.*;  

  

public class ToDoServlet extends HttpServlet {

As you can see, servlet classes must extend the javax.servlet.HttpServlet class. You can view documentation on this and related classes in the J2EE API Specification.

Our servlet will use an instance of our ToDoList class, which we want to create when the servlet is first loaded. We can perform initialization tasks like this in the init() method, which the server will call when it loads the servlet:

  private ToDoList toDoList;  

  

  // Initialize global variables  

  public void init() throws ServletException {  

    toDoList = new ToDoList(getInitParameter("jdbcDriver"),  

                            getInitParameter("jdbcConnectionString"));  

  }

You may recall that the ToDoList constructor takes the name of the JDBC driver you want to use, and a JDBC connection string so that it can connect to your database. Rather than hard-coding these strings into our servlet, we use this code, which uses initialization parameters for these values, so that they can be configured without recompiling the servlet. We’ll look more at this later.

You’ll notice that the init() method, like all standard servlet methods, can throw a ServletException. This exception is used to let the server know that something went wrong in the servlet. We’ll see how this works a bit later.

Next up is the doGet() method, which handles normal browser requests. It takes two parameters: an HttpServletRequest that contains detailed information about the browser request, and a HttpServletResponse that the servlet can use to control its response to the browser:

  public void doGet(HttpServletRequest request, HttpServletResponse response)  

      throws ServletException, IOException {

Once again, the method is able to throw a ServletException to signal an error in the servlet. The servlet specification also allows this function to throw an IOException, in case there is a problem reading the request, or writing the response.

In response to normal browser requests, we want to display the current to-do list and give the user the ability to add items to the list, and also to delete existing items on the list. First, we must let the HttpServletResponse object know what content type we will be sending back to the browser:

    response.setContentType("text/html");

Now we can ask it for a PrintWriter object that we can use to send HTML code to the browser:

    PrintWriter out = response.getWriter();

The PrintWriter object lets us send HTML code to the browser using its println() method:

    out.println("
                "  \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\">");  

    out.println("");  

    out.println("");  

    out.println("To-Do List");  

    out.println("
                "content=\"text/html; charset=iso-8859-1\" />");

If this doesn’t look very pretty to you, then you’ve spotted the biggest weakness of servlets: the HTML markup is mixed in with the Java logic of your application, which makes it difficult to read and maintain.

Pressing on, we want to link a CSS style sheet to our page:

    out.println("
                request.getContextPath() + "/styles.css\" />");  

    out.println("");  

    out.println("");

Since we don’t yet know which directory of the web server our application will be installed in, we don’t know the path at which resources like style sheets and images will be available. The above code uses the request object’s getContextPath() method to obtain the path to the root of our application, and from there we can point to the styles.css file, which we’ll create a little later.

Next up, we’ll display our to-do list in an HTML form menu. We can start by grabbing an Iterator from our ToDoList with its getToDoItems() method. Then, we’ll check to see if it contains any items with its hasNext() method:

    Iterator toDoItems = toDoList.getToDoItems();  

    if (toDoItems.hasNext()) {

We want the form to submit back to the same URL, so that this servlet can handle that request as well, so we use the getRequestURI() method to get it:

      out.println("
                  "\" method=\"post\">");

Since HTML form menus turn into drop-down lists with a size of 1, we want the Math.max(2, toDoList.getItemCount()) + "\">");

We can then loop through the toDoItems with a while loop. Each time we move through the loop, we pull a ToDoItem out of the Iterator with next(). Since it doesn’t know it contains ToDoItems, we need to cast them to the right class before we can use them:

      while (toDoItems.hasNext()) {  

        ToDoItem toDoItem = (ToDoItem) toDoItems.next();

For each item, we want to create a tag with the item’s ID as its value. Outputting the ID is no problem, since it’s just an integer, but the to-do item itself gets tricky. What if the to-do item contains HTML code — possibly even malicious script code? We don’t want to output that stuff and have it interpreted by the browser as part of our site! The solution is to escape any special characters in the value before printing it out.

This is another area where servlets are weak: there is no built-in HTML escaping functionality in the servlet API or in Java in general (at least none that is accessible to us). Thankfully, this is a longstanding issue, and 3rd party classes have been created to do the job. The one I’ve chosen is developed and distributed by AnyWare. The class is called uk.co.anyware.html.HTMLEscaper, and its source code and license are included in the code archive I’ve provided below.

To use HTMLEscaper, drop the class (and source code if you want to hold onto it) into the WEB-INF/classes directory and add the required import to the top of the ToDoServlet class:

import uk.co.anyware.html.*;

With the class in hand, we can now safely output the to-do item. We’ll also polish off the rest of the form with a submit button for deleting selected items:

      out.println("");  

      out.println("");  

      out.println("");  

    }

We’ll finish off the page with a second form, this time for submitting new to-do items:

    out.println("
                "\" method=\"post\">");  

    out.println("");  

    out.println("");  

    out.println("
");  

  

    out.println("");  

    out.println("");  

    out.close();  

  }

That takes care of displaying the initial page to the user, but we’ve now got two forms submitting back to this same servlet!

Both of these forms submit using the POST method (method="post"), so we could handle them in the servlet’s doPost() method. But to make the servlet as flexible as possible we’ll also support submissions for adding new to-do items, and deleting existing ones, via GET requests. To do this, we’ll simply feed POST requests back into our doGet() method:

  public void doPost(HttpServletRequest request, HttpServletResponse response)  

      throws ServletException, IOException {  

    doGet(request, response);  

  }

At the top of doGet(), we now need to check for and process our form submissions. Here’s the code for handling new to-do items:

    String newToDo = request.getParameter("newtodo");  

    if (newToDo != null) {  

      toDoList.addItem(newToDo);  

  

      // Redirect to self  

      response.sendRedirect(request.getRequestURI());  

      return;  

    }

The getParameter() method lets us retrieve a submitted value with a given name as a string. If the value isn’t null, we know we have a submission on our hands. We add it to the to-do list using its addItem method, then redirect the browser to the current page with the response’s sendRedirect() method.

If we didn’t redirect the browser, the rest of the doGet() method would indeed display the updated to-do list for the user, but refreshing the page would cause the form submission to be sent again, resulting in a duplicate entry on the to-do list. Redirecting the browser back to the same page forces the browser to think of it as a separate request, and therefore it will not resubmit the form when refreshing the page.

The code for processing deleted items is very similar, except that it must convert the submitted string into an integer for the to-do list’s deleteItem() method:

    String deleteid = request.getParameter("deleteid");   

    if (deleteid != null) {   

      try {   

        toDoList.deleteItem(Integer.parseInt(deleteid));   

   

        // Redirect to self   

        response.sendRedirect(request.getRequestURI());   

        return;   

      }   

      catch (NumberFormatException e) {   

        throw new ServletException("Bad deleteid value submitted.", e);   

      }   

    }

The conversion is achieved by the Integer.parseInt() method but, if the value submitted cannot be converted into a number, it will throw a NumberFormatException. If this happens, our code catches the exception and throws a ServletException (to which we pass the NumberFormatException as a root cause).

GA_googleFillSlot(“Articles_6_300x250″);

Remember, all standard servlet methods are allowed to throw ServletExceptions to let the server know something has gone wrong. That’s exactly what we’re doing here. When the code throws the ServletException, the server running the servlet catches it and displays an appropriate error message in the user’s browser. You can configure most Java servers to control how much technical detail is included in such error pages.

Believe it or not, that’s it for the servlet! You still have to compile it, though, and that’s a little tricky. You see, the HttpServlet class that our servlet extends is included in the libraries distributed with every Java server, and you need that class to be able to compile your subclass.

In Tomcat 5.x, the servlet library is called servlet-api.jar and it can be found in the common\lib directory of your Tomcat installation. So you can compile your servlet by including that JAR file in the classpath:

javac -classpath   

".;c:\Program Files\Apache Group\Tomcat 5.5\common\lib\servlet-api.jar"   

com/sitepoint/*.java uk/co/anyware/html/*.java

Here’s what your file and directory structure should look like now:

/WEB-INF/classes/com/sitepoint/ToDoItem.class   

/WEB-INF/classes/com/sitepoint/ToDoItem.java   

/WEB-INF/classes/com/sitepoint/ToDoList.class   

/WEB-INF/classes/com/sitepoint/ToDoList.java   

/WEB-INF/classes/com/sitepoint/ToDoServlet.class   

/WEB-INF/classes/com/sitepoint/ToDoServlet.java   

/WEB-INF/classes/uk/co/anyware/html/HTMLEscaper.class   

/WEB-INF/classes/uk/co/anyware/html/HTMLEscaper.java   

/WEB-INF/lib/mysql-connector-java-version-bin.jar

We have two things left to add to complete our Java web application. The first is the styles.css style sheet referenced by our servlet:

body, p, td, th {   

  background: #fff;   

  color: #000;   

  font: medium Verdana, Arial, Helvetica, sans-serif;   

}   

   

select {   

  width: 100%;   

}

Drop this in the main application directory, which also contains the WEB-INF directory.

The other thing we need is the XML configuration file for the application, web.xml. This file is called the deployment descriptor. It must start with a tag like this one (again, any decent IDE will write this boilerplate code for you):

   


    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   

    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"   

    version="2.4">

Next up, we provide a name for our web application:

  ToDoServlet

Now we’ll configure our servlet. We give it a name and specify its class:

     

    toDo   

    com.sitepoint.ToDoServlet

Now, remember the init() method of our servlet used two initialization parameters: one for the JDBC driver class name, and one for the JDBC connection string. We provide values for those parameters here:

       

      The JDBC driver class.   

      jdbcDriver   

      com.mysql.jdbc.Driver   

       

       

      The JDBC connection string.   

      jdbcConnectionString   

      jdbc:mysql://localhost/todo?user=root&password=password

Finally, we supply a servlet mapping, which sends requests to a given URL to the servlet. For our example, we’ll direct requests for index.html in the root of our application to our servlet:

     

    toDo   

    /index.html

That’s it for our application! Here’s the complete list of files:

/styles.css   

/WEB-INF/web.xml   

/WEB-INF/classes/com/sitepoint/ToDoItem.class   

/WEB-INF/classes/com/sitepoint/ToDoItem.java   

/WEB-INF/classes/com/sitepoint/ToDoList.class   

/WEB-INF/classes/com/sitepoint/ToDoList.java   

/WEB-INF/classes/com/sitepoint/ToDoServlet.class   

/WEB-INF/classes/com/sitepoint/ToDoServlet.java   

/WEB-INF/classes/uk/co/anyware/html/HTMLEscaper.class   

/WEB-INF/classes/uk/co/anyware/html/HTMLEscaper.java   

/WEB-INF/lib/mysql-connector-java-version-bin.jar

You’re now ready to bundle this application up so that it’s ready to be deployed on a Java-capable server. To do this, you need to use the jar utility included with the JDK. If you’ve added the bin directory of your JDK to your system path, you should be able to run it from the command prompt just by typing jar.

Move to your working directory for the application (the one that contains styles.css and WEB-INF), and type this command:

jar cvf ToDoServlet.war .

This will produce a file called ToDoServlet.war containing your application. It’s actually a ZIP file in disguise.

You now need to deploy this application on your server. Different servers provide different ways of doing this. If you’re using Tomcat, simply copy the ToDoServlet.war file into the webapps directory of your installation. After a few moments, Tomcat will automatically extract the file into a new directory. You can then go and edit the web.xml file to make sure the JDBC connection string contains the correct details for your database server.

Once that’s done, you should be ready to run your application. Load up http://localhost:8080/ToDoServlet/index.html in your browser (assuming Tomcat is running on port 8080 on your local machine). Here’s what you should see:

Have a play with the page. It should work just as you’d expect. Here’s the WAR file (complete with source code if you unzip it):

Download the code. (250KB)

Old School JSP

You’re ready for your next step along the path to understanding the state of the art in Java web application development. So far, we’ve looked at servlets: Java classes that are designed to respond to web browser requests. Using a servlet, we have assembled a simple web interface to our database driven to-do list. And while it works, it would be a pain in the butt to write practical web applications this way, with the application logic all mixed in with the HTML code for the page.

JavaServer Pages (JSP) were created to overcome this weakness of servlets. Instead of writing a Java class with HTML code in it, you write an HTML page with Java code in it. The server then converts this page into a Java servlet on the fly in order to process page requests. As we’ll see, reversing our approach in this way solves some problems, but creates some new ones.

Starting with the to-do list web application we built a moment ago, let’s do away with our pesky servlet and replace it with a JavaServer page that does the same thing: todo.jsp. Here’s the updated file and directory structure for our application:

/todo.jsp    

/styles.css    

/WEB-INF/web.xml    

/WEB-INF/classes/com/sitepoint/ToDoItem.class    

/WEB-INF/classes/com/sitepoint/ToDoItem.java    

/WEB-INF/classes/com/sitepoint/ToDoList.class    

/WEB-INF/classes/com/sitepoint/ToDoList.java    

/WEB-INF/classes/uk/co/anyware/html/HTMLEscaper.class    

/WEB-INF/classes/uk/co/anyware/html/HTMLEscaper.java    

/WEB-INF/lib/mysql-connector-java-version-bin.jar

GA_googleFillSlot(“Articles_6_300x250″);

Let’s get started writing our todo.jsp file. Open up your favourite text editor and we’ll get cooking!

JSP files look a lot like HTML files, except that scattered throughout them will be special JSP tags. As a general rule, all JSP tags start with <% and end with %>. As we look at more modern and advanced ways of working with JSP in future, this is a rule that will be broken but, for now, it’s okay if you take this as gospel.

The first thing we need to do is provide some information about the page. This is done with a page directive. Directives are a type of JSP tag that contain various settings and other types of configuration information. Directives have an @ sign following their opening <%. Here’s our page directive:

<%@ page import="java.util.*,com.sitepoint.*,uk.co.anyware.html.*" %>

The most common use for a page directive is to import Java packages that will be used by the Java code in the JSP file. In this case, we’ve indicated that we need classes from java.util, com.sitepoint, and uk.co.anyware.html. These same packages were imported by our to-do list servlet (the code for which you might like to have nearby for comparison).

We can then proceed to write our page much as we would any (X)HTML file:


    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">    

    

    

  To-Do List    

  
      content="text/html; charset=iso-8859-1" />    

  
      href="<%= request.getContextPath() %>/styles.css" />

Look closely, and you’ll see another JSP tag in there: <%= request.getContextPath() %>. This is what we call an expression, as indicated by the = sign following the opening <% in the tag. Expressions are used to output the values of Java code; in this case, we’re outputting the value returned by the getContextPath() method of the request object — the root directory of our web application, which the browser needs to locate the styles.css file.

Yes, JSP code, just like servlet code, has access to the browser’s request through a variable called request. There is also a response variable for the browser’s response. Both of these variables are called implicit objects — they’re created implicitly for you.

Other implicit objects include out, an object that works just like the PrintWriter that is used in a servlet to send output to the browser, session, an object for storing values over the course of a particular user’s visit to your site, and application, an object for storing values for use throughout your application.

Now, just as our servlet relied on a ToDoList object to do a lot of the work of the application, so will our JSP file. We need to declare this object, and for this we need another JSP tag: a declaration.

<%!    

private ToDoList toDoList;    

    

public void jspInit() {    

  toDoList = new ToDoList(getInitParameter("jdbcDriver"),    

      getInitParameter("jdbcConnectionString"));    

}    

%>

As you can see, declarations are indicated by an exclamation mark (!) following the opening <%, and contain Java property and method declarations just like those you’d find in a Java class.

In this case, we’ve declared a ToDoList object called toDoList, and we’ve written a method named jspInit() that creates this object from initialization parameters, just as we did in our servlet’s init() method. While init() is a special method for servlets that is called by the server before a servlet is used for the first time, jspInit() is a special method that is called automatically to initialize JSP files.

Next up is the code that will process form submissions in this page. You’ll remember from our servlet that the page will contain two forms: one for adding items to the to-do list, and one for deleting them. The code for processing these submissions will be identical in our JSP, except that it goes inside yet another type of JSP tag: a scriptlet.

<%    

String newToDo = request.getParameter("newtodo");    

if (newToDo != null) {    

  toDoList.addItem(newToDo);    

  response.sendRedirect(request.getRequestURI());    

  return;    

}    

    

String deleteid = request.getParameter("deleteid");    

if (deleteid != null) {    

  try {    

    toDoList.deleteItem(Integer.parseInt(deleteid));    

    

    response.sendRedirect(request.getRequestURI());    

    return;    

  }    

  catch (NumberFormatException e) {    

    throw new ServletException("Bad deleteid value submitted.", e);    

  }    

}    

%>

When JSP was first conceived, scriptlets were expected to be the most common JSP tag type, so they are indicated with simple <% and %> delimiters — no special character inside the start of the tag. The Java code inside a scriptlet is executed every time the page is requested.

With the form processing taken care of, all that’s left is to produce the forms themselves. First up, we have our to-do list, which displays the current to-do items and allows the user to delete them:

    

  <%    

  Iterator toDoItems = toDoList.getToDoItems();    

  if (toDoItems.hasNext()) {    

    %>    

        

          

          

    
    

    <%    

  }    

  %>

Looks like a bit of a mess, doesn’t it? What we have here is a mixture of HTML code, JSP scriptlets, and JSP expressions. Let’s break it down.

  <%    

  Iterator toDoItems = toDoList.getToDoItems();    

  if (toDoItems.hasNext()) {    

    %>    

    ...    

    <%    

  }    

  %>

The first scriptlet gets an Iterator object containing the items in the to-do list. Our servlet did the exact same thing. Since we don’t need to display the to-do list if it doesn’t contain any items, we use an if statement to check if it does using the Iterator‘s hasNext() method.

All of the code for the form then goes inside this if statement. The closing brace of the if statement is in the last scriptlet of the page. As you can see, the Java code inside a scriptlet doesn’t need to be self-contained; you can think of the HTML code between your JSP tags as instructions to output that HTML code, with the scriptlets providing the logic for when and how that HTML should appear.

In the form, we use JSP expressions to output required values in our

and

...

Finally, we need to output an tag for each item in our to-do list. The code is once again remarkably similar to our servlet, as we use a while loop to do the job:

        <%    

        while (toDoItems.hasNext()) {    

          ToDoItem toDoItem = (ToDoItem) toDoItems.next();    

          %>    

              

          <%    

        }    

        %>

It’s a mess at first glance, but if you look carefully (or better yet, if you have an editor that highlights JSP tags in a different colour), you can see how the logic is in JSP scriptlets, and the rest of the code is just HTML with JSP expressions to output dynamic values.

The form for adding new to-do list items is a piece of cake compared to the first one:

That takes care of our JSP file! The only thing left is to update the web.xml configuration file for our application to make the initialization parameters (jdbcDriver and jdbcConnectionString) available to our JSP file:

    


    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"    

    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"    

    version="2.4">    

  ToDoJSP    

      

    toDo    

    /todo.jsp    

        

      The JDBC driver class.    

      jdbcDriver    

      com.mysql.jdbc.Driver    

        

        

      The JDBC connection string.    

      jdbcConnectionString    

      jdbc:mysql://localhost/todo?user=root&password=password    

        

      

      

    toDo    

    /todo.jsp

There are two significant changes from the web.xml file we used with our servlet:

Instead of using a tag to indicate the servlet for which we are providing parameters, we have a tag to indicate the JSP file.
The tag in the points to the JSP file as well.

With those changes made, you’re ready to bundle up the application and deploy it on your server. Unlike servlets, you don’t need to compile JSP files in advance — the server will convert them to servlets and compile them for you on the fly. You do, however, still need to compile the classes that your JSP uses (ToDoList, ToDoItem, HTMLEscaper).

As with the servlet, use the jar command-prompt utility to create a WAR file containing your application:

jar cvf ToDoJSP.war .

Drop this file in Tomcat’s webapps directory to deploy it (or deploy it using whatever Java-compatible server you prefer), and edit the deployed web.xml file to match your database configuration.

Then load http://localhost:8080/ToDoJSP/todo.jsp to try out your application. You should see your familiar to-do list interface, this time generated by a JSP.

Here’s the finished WAR file, including source code, for you to experiment with:

Download the code. (250KB)

Now, you’ll recall that the whole point of JSP was to overcome the messiness of mixing HTML code into the Java code of a servlet. If you’ve looked at the code for our new JSP file, I’d forgive you for being skeptical about whether we’ve achieved our aim.

Our to-do list JSP file is written with what I call "old school JSP". It’s pure JSP, as it was originally conceived years ago, with none of the modern amenities. In the rest of this article, I’ll show you how to modify it using current and advanced features of JSP. First of all, we’ll bring servlets back into the picture (but in a much simpler form!), then we’ll look at standards like JavaBeans, the Java Standard Tag Library, and JSP Expression Language.

Generally speaking, our goal will be to get rid of all the Java code in the JSP file, either by replacing it with more designer-friendly tag constructs, or by moving it into external, independent Java classes. By the time we’re done, you’ll know how to write a JSP file so that it is barely distinguishable from a standard HTML file.

Kickin’ It MVC-Style

Still following along? I’ve already shown you how to convert a to-do list servlet into a JSP. Unfortunately, what we got wasn’t much better in terms of readable code — Java code embedded in an HTML document isn’t a whole lot more readable than HTML code embedded in a Java class.

What to do? Well, so far we have two tools at our disposal: servlets and JSPs. Servlets are great for containing Java code, JSPs are great for containing HTML code. The answer is to split our application apart so that the Java code goes into servlets, and the HTML code goes into JSPs.

A standard approach for this called Model 2 Architecture has been around for a long time, but lately it has become known by the more descriptive name: Model-View-Controller (MVC).

GA_googleFillSlot(“Articles_6_300x250″);

The idea is to break the application into three parts:

The model: a collection of Java classes that perform the actual work of the application (often called the business logic), independant of the web interface.
The view, a collection of JSPs, or some other technology, that produces the actual web pages that the users see.
The controller, one or more servlets that process browser requests by telling the model what to do and then handing over to the view to respond.

Now I could go on and on about this all day, but it’s easier to see through an example, so let’s get to work on modifying our to-do list application.

The model is usually the best place to start, as you can usually write it without worrying much about the web interface. In the case of our to-do list application, we already have our model: it’s made up of the classes ToDoList and ToDoItem. These two classes do all the work of managing the to-do list.

While we’re looking at these classes, let’s make one minor tweak to the getToDoItems method: we’ll make it return a List rather than an Iterator. This allows for a bit more flexibility in how the to-do list items may be used when they are retrieved through this method.

  public List getToDoItems() {     

    refreshList();     

    return (List)list.clone();     

  }

Next, let’s work on our controller. We know we’ll have three different kinds of requests coming from the browser: simple requests to view the to-do list, form posts for adding new items to the list, and form posts for deleting existing items from the list.

We now have a choice: do we write one servlet that knows how to handle all these different request types, or do we write three simple, specialized servlets each of which knows how to handle one type of request? There’s no right answer, as there are advantages to each approach, but let’s try to keep our classes simple and go for multiple servlets.

We’ll start with ToDoServlet, which will handle requests to view the to-do list. The first thing this servlet needs to do is set up the model — an instance of ToDoList. Back when we first looked at servlets, we did this with the init() method of the servlet, which stored the ToDoList in an instance variable of the servlet.

This time, that won’t quite do the trick, because we want all three of our servlets to be able to access the model. We can’t create the ToDoList in one servlet’s initialization procedure because one of the other servlets might need it first, and we can’t store it in an instance variable because the other servlets wouldn’t be able to see it at all. What we need is a way to create the model when the web application first starts up, and a place to store it where any servlet can get at it.

To perform initialization tasks for the entire application, we must use a ServletContextListener. Rather than a class to extend, this is an interface, which any class can implement. Since our "main" servlet is a good place to do this stuff, we’ll make it implement that interface:

public class ToDoServlet extends HttpServlet     

    implements ServletContextListener {

When a class implements ServletContextListener, it must contain two methods: contextInitialized, which performs application initialization tasks, and contextDestroyed, which performs application cleanup:

  public void contextInitialized(ServletContextEvent sce) {     

    ServletContext sc = sce.getServletContext();     

    sc.setAttribute("toDoList",     

        new ToDoList(sc.getInitParameter("jdbcDriver"),     

                     sc.getInitParameter("jdbcConnectionString")));     

  }     

     

  public void contextDestroyed(ServletContextEvent sce) {     

  }

All the action here is in contextInitialized, since we don’t need to do anything special when the application shuts down. As you can see, when they’re called, both of these methods receive a ServletContextEvent from which we can get a reference to the ServletContext. The ServletContext is an object that represents the web application as a whole — it’s the context in which the servlet is running. All servlets and JSPs have access to the ServletContext; therefore, it provides the perfect place to store our model!

The ServletContext lets you set and get attributes, which are simply application-wide values associated with string labels. We’ll store our model, a new ToDoList object, in an attribute labelled "toDoList".

Before we move on, have a close look at the code that creates the ToDoList:

        new ToDoList(sc.getInitParameter("jdbcDriver"),     

                     sc.getInitParameter("jdbcConnectionString")));

As we’ve done previously, we’re getting the JDBC driver and connection string values required by this class from initialization parameters, but because we’re performing initialization for our entire application, the initialization parameters for the ToDoServlet are not yet available! That’s why we’re calling the getInitParameter method of the ServletContext object, not the servlet itself, as we’re used to doing. These are known as context initialization parameters, as opposed to servlet initialization parameters.

Now we’ve got a ServletContextListener that’s ready to initialize our application, as long as it gets the context initialization parameters it needs. As you may have guessed, we need to add some things into our web.xml file to make this work:

     


    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"     

    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4">     

  ToDoMVC     

       

    com.sitepoint.ToDoServlet     

       

       

    The JDBC driver class.     

    jdbcDriver     

    com.mysql.jdbc.Driver     

       

       

    The JDBC connection string.     

    jdbcConnectionString     

    jdbc:mysql://localhost/todo?user=root&password=password

The tag lets the application know about the context listener we’ve provided, while the tags set up our application-wide context initialization parameters.

Now, before we got caught up in all this application initialization stuff, I seem to remember that we were writing a servlet. So let’s take a look at the doGet and doPost methods:

  public void doGet(HttpServletRequest request, HttpServletResponse response)     

      throws ServletException, IOException {     

    ToDoList toDoList = (ToDoList)getServletContext().getAttribute("toDoList");     

    List toDoItems = toDoList.getToDoItems();     

    request.setAttribute("toDoItems", toDoItems);     

     

    RequestDispatcher view = request.getRequestDispatcher("/todo.jsp");     

    view.forward(request, response);     

  }     

     

  public void doPost(HttpServletRequest request, HttpServletResponse response)     

      throws ServletException, IOException {     

    doGet(request, response);     

  }

Look at that! A servlet with no embedded HTML code! How is such a thing possible? Well remember, this servlet is merely the controller in our MVC design: after getting things done with the model, it hands the request to the view to display the actual web page. Looking closely at the doGet method, you’ll see that this is exactly what it does:

    ToDoList toDoList = (ToDoList)getServletContext().getAttribute("toDoList");     

    List toDoItems = toDoList.getToDoItems();     

    request.setAttribute("toDoItems", toDoItems);

Here, it fetches the model (the ToDoList stored in a servlet context attribute), uses it to get a List of the to-do list items, and then stores that List someplace where the view will be able to find it — namely, in the request object. It turns out that the request object supports attributes too, and this is the perfect way to pass values to the view that it will need to build the page.

With the heavy lifting done, we’re ready to pass the request to the view (in this case, a JSP called todo.jsp in the root of our application):

    RequestDispatcher view = request.getRequestDispatcher("/todo.jsp");     

    view.forward(request, response);

At a glance, this may seem a bit confusing, but this is the formula we will always use to forward requests from a servlet to a JSP. We get a RequestDispatcher object for the location we want to forward to (in this case, "/todo.jsp" specifies the todo.jsp file in the root of the application), then we call its forward method, passing it the request and response objects it will need to do the job.

Okay, so I’ve had to yammer on a bit to explain all the new stuff that’s going on in this servlet, but if you step back and look at the code, you’ll find it’s actually pretty neat and tidy. And since they aren’t burdened with all the application setup stuff, our other two servlets are even neater and tidier!

package com.sitepoint;     

     

import javax.servlet.*;     

import javax.servlet.http.*;     

import java.io.*;     

     

public class AddToDoServlet extends HttpServlet {     

  public void doPost(HttpServletRequest request, HttpServletResponse response)     

      throws ServletException, IOException {     

     

    String newToDo = request.getParameter("newtodo");     

    if (newToDo != null) {     

      ToDoList toDoList = (ToDoList)getServletContext().getAttribute("toDoList");     

      toDoList.addItem(newToDo);     

    }     

    response.sendRedirect("index.html");     

  }     

}

package com.sitepoint;     

     

import javax.servlet.*;     

import javax.servlet.http.*;     

import java.io.*;     

     

public class DeleteToDoServlet extends HttpServlet {     

  public void doPost(HttpServletRequest request, HttpServletResponse response)     

      throws ServletException, IOException {     

    String deleteid = request.getParameter("deleteid");     

    if (deleteid != null) {     

      try {     

        ToDoList toDoList = (ToDoList)getServletContext().getAttribute("toDoList");     

        toDoList.deleteItem(Integer.parseInt(deleteid));     

      }     

      catch (NumberFormatException e) {     

        throw new ServletException("Bad deleteid value submitted.", e);     

      }     

    }     

    response.sendRedirect("index.html");     

  }     

}

You might be surprised to note that these servlets don’t actually forward to a JSP after they’ve done their work. Instead, they redirect the browser to "index.html", which we’ll shortly configure to point to our main ToDoServlet.

Because we want to show the user the updated to-do list after adding or deleting an item, we could forward the request to /todo.jsp, but, as I explained previously, this would lead to problems if the user were to refresh the browser afterward. The browser would re-submit the item addition/deletion request, causing errors or duplicate list entries. Redirecting instead of forwarding gets around this by having the browser make a new request, which is safe to repeat, after it has submitted the form.

To polish off our servlets, we need to assign URLs to each of them in our web.xml file. We’ll use /index.html for the ToDoServlet, since we want it to come up by default when a user loads our application directory. AddToDoServlet and DeleteToDoServlet will get /AddItem.do and /DeleteItem.do respectively, following the convention of giving "action" URLs .do extensions in Java web apps.

       

    todoservlet     

    com.sitepoint.ToDoServlet     

       

       

    todoservlet     

    /index.html     

       

       

    addtodoservlet     

    com.sitepoint.AddToDoServlet     

       

       

    addtodoservlet     

    /AddItem.do     

       

       

    deletetodoservlet     

    com.sitepoint.DeleteToDoServlet     

       

       

    deletetodoservlet     

    /DeleteItem.do

With our servlets done, all that’s left is to build the view for our application. For this example, all we need is a single JSP file: todo.jsp.

Now that we’ve pulled all our initialization and request processing code out into servlets, our JSP file looks a lot more reasonable:

<%@ page import="java.util.*,com.sitepoint.*,uk.co.anyware.html.*" %>     

     

     

     

  To-Do List     

       

       

     

     

  <%     

  List toDoItems = (List)request.getAttribute("toDoItems");     

  Iterator it = toDoItems.iterator();     

  if (it.hasNext()) {     

    %>     

         

           

           

    
     

    <%     

  }     

  %>

If you understood the original JSP we built, this one should be a piece of cake! The scriptlet code simply pulls the List out of the request‘s "toDoItems" attribute to produce the list of to-do items, and our two forms now submit to the .do URLs we assigned to the corresponding servlets. Beyond those changes, it’s the same old JSP with a lot less Java code.

And there we have it: an MVC Java web application! Here’s the directory structure:

/todo.jsp     

/styles.css     

/WEB-INF/web.xml     

/WEB-INF/classes/com/sitepoint/AddToDoServlet.class     

/WEB-INF/classes/com/sitepoint/AddToDoServlet.java     

/WEB-INF/classes/com/sitepoint/DeleteToDoServlet.class     

/WEB-INF/classes/com/sitepoint/DeleteToDoServlet.java     

/WEB-INF/classes/com/sitepoint/ToDoItem.class     

/WEB-INF/classes/com/sitepoint/ToDoItem.java     

/WEB-INF/classes/com/sitepoint/ToDoList.class     

/WEB-INF/classes/com/sitepoint/ToDoList.java     

/WEB-INF/classes/com/sitepoint/ToDoServlet.class     

/WEB-INF/classes/com/sitepoint/ToDoServlet.java     

/WEB-INF/classes/uk/co/anyware/html/HTMLEscaper.class     

/WEB-INF/classes/uk/co/anyware/html/HTMLEscaper.java     

/WEB-INF/lib/mysql-connector-java-version-bin.jar

Download the code. (250KB)

This application is starting to look pretty darned good, even if I do say so myself. Its major weakness continues to be the Java scriptlet code in the JSP. We’ve gotten rid of most of the Java code from this file, but what’s in there would still be pretty confusing for a web designer. The next step in the grand tour will be to look at some of the features of modern JSP that allow us to dispense with these scriptlets in favour of tags and expressions.

A Crash Course in Java-less JSP

It’s time to take the Java out of JavaServer Pages.

We’ve split our to-do list web application into three parts: the model, classes that manage the data at the heart of our application; the controller, servlets that process incoming requests and then send display values to the view; and the view, JSP files that generate web pages from those display values.

While this approach generally did a good job of separating the Java application logic from the HTML user interface code, it still left us with some Java code in our JSP file(s). This code was needed to grab the values supplied by the controller and massage them into our HTML interface. We’ll call this display logic.

Now, I’ll show you how to get rid of the Java code ftrom your JSP files, and implement that display logic with a simpler and more powerful alternative.

Let’s start by reviewing just what the Java display logic in our example’s JSP file does. First, it gets the list of items supplied by the controller:

  List toDoItems = (List)request.getAttribute("toDoItems");      

  Iterator it = toDoItems.iterator();

Then, it checks if there are any items in the list:

  if (it.hasNext()) {

To keep the HTML

Display logic is then used to process each of the to-do list items in turn:

        while (it.hasNext()) {      

          ToDoItem toDoItem = (ToDoItem) it.next();

Finally, display logic is used to extract the ID and text content of each to-do list item, and to escape any special characters that may appear in the text:

Given that this is a relatively simple application, that’s quite a bit of Java code still lingering in a file which will ostensibly be created and edited by web designers — people who typically aren’t well versed in the finer points of the Java language and APIs.

So, what to do? Obviously this display logic is required, but we need a better way of implementing it than including Java code in our page.

There are actually quite a few alternatives that have been written by various groups floating around the Web. From simple JSP tag libraries (collections of custom tags that you can mix with your HTML to implement your display logic) to complete JSP replacements, the galaxy of options can be humbling. The solution proposed by the JSP 2.0 standard is a combination of a tag library called the JSP Standard Tag Library (JSTL) and a syntax for accessing Java values without Java code called JSP Expression Language (EL).

GA_googleFillSlot(“Articles_6_300x250″);

While EL is built into JSP 2.0, and therefore is available automatically in your JSP files, JSTL is a separate library that must specifically be included in your web application before you can use it. In Tomcat 5.x, you can grab the JSTL 1.1 library files from the jsp-examples web application included with the server. Simply go into the webapps/jsp-examples/WEB-INF/lib subdirectory of the server installation, grab jstl.jar and standard.jar, and copy them into the WEB-INF/lib subdirectory of the to-do list web app.

You can now use JSTL tags in your JSP files. Let’s modify the todo.jsp file to produce the same to-do list user interface without any Java scripting.

First, we need to declare our intention to use JSTL tags in the file. JSTL is actually divided into a number of sub-libraries, so you don’t have to load the entire library if you just want to use a couple of its tags. The most commonly-used tags are found in the Core sub-library, which we can load using this @taglib directive immediately following the @page directive at the top of the file:

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

Here’s the first piece of Java code in our todo.jsp file. We use it to get the context path (the root) of our web application, so that we can locate the CSS file to be used by the page:

For example, if our web application is installed in http://www.example.com/todo, then the context path for the application is /todo and therefore our style sheet will be correctly located at /todo/styles.css.

The tag of the JSTL Core library lets us produce URLs relative to the context path automatically. Here’s how the adjusted code looks:

  " />

Yes, you read right. That’s a JSTL tag within the attribute value of an HTML tag. XML sticklers may grit their teeth at this, but JSP was never meant to be valid XML. For XHTML standards compliance, you just need to make sure that the code generates valid XML, which this will.

The next chunk of Java code in our todo.jsp file is a little more challenging. It grabs the List object that the controller stored in a request object attribute called toDoItems, and checks if it contains any to-do items:

  <%      

  List toDoItems = (List)request.getAttribute("toDoItems");      

  Iterator it = toDoItems.iterator();      

  if (it.hasNext()) {      

    %>

The tag lets us test a condition and output the contents of the tag only when that condition is true. The tag looks like this:

...

But how do we specify a condition? That’s where JSP Expression Language (EL) comes in. The test attribue of the tag takes an EL expression as the condition to be tested.

EL was designed specifically to be really, really good at fetching values out of request, session, and application attributes. As a matter of fact, the EL expression that will fetch the toDoItems request attribute is simply this:

${toDoItems}

For our purposes, we actually want to go a step further and check how many items are in the toDoItems list. To do this, we need to use an EL function, which requires another JSTL sub-library to be added with a @taglib directive at the top of the page:

<%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions" %>

With that done, we can get the number of items in the list with this EL expression:

${fn:length(toDoItems)}

And we can determine if the list contains items with this expression:

${fn:length(toDoItems) > 0}

We can now write the tag to test this condition:

...

Next, we’ll use JSTL not to replace some Java design logic, but to improve some pure HTML in our todo.jsp file. The form that displays the to-do list items and allows the user to delete them begins with this

tag:

This is just fine as long as our JSP is in the root directory of our web application, but if we were to move it into a subdirectory, the action attribute of this tag would no longer point to DeleteItem.do in the root of the application. To ensure this attribute always points to the correct URL, we can use a tag just like we used for the style sheet URL above:

    " method="post">

Incidentally, we can make the same change to the second tag on the page, which points to AddItem.do.

The next piece of Java display logic in todo.jsp is a bit trickier to reproduce with JSTL/EL:

list with a size equal to the number of items in toDoItems, but no less than 2, using only standard JSTL/EL features, we would need to implement this logic more verbosely:

The JSTL tag lets us set a variable for use in EL expressions in the rest of the page. In this case, we’d set it to the number of items in toDoItems (which we’d again get with the fn:length EL function). We’d then use a to test if the value was less than 2, in which case we’d use another to set the variable to that minimum.

We could then go ahead and output the value with an expression in our

Yes — you can use EL expressions in HTML tag attributes too.

This solution would be pretty messy, though. Wouldn’t it be nice if we had an EL function that did the same thing as Math.max? As it turns out, extending EL with your own functions is pretty easy.

First, you need to create a Java class with a public, static method that does what you want your EL function to do. For this project, let’s create a class called com.sitepoint.jsp.Functions (in com/sitepoint/jsp/Functions.java). The code for this class will be very simple:

package com.sitepoint.jsp;      

      

public class Functions {      

  public static int max(int i1, int i2) {      

    return Math.max(i1, i2);      

  }      

}

Next, we need to define a custom tag library to set this class’s max method as a custom EL function. To do this, create an XML file called functions.tld and put it in the WEB-INF directory of the project. Aside from the first tag (which is always the same), most of the code is fairly self-explanatory:

      


    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"      

    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd"      

    version="2.0">      

  1.0      

  Functions      

  http://www.sitepoint.com/jsp/taglibs/functions      

        

    max      

    com.sitepoint.jsp.Functions      

    int max(int, int)

What this file does is associate a unique identifier, in the form of a URL (http://www.sitepoint.com/jsp/taglibs/functions), with a library of EL functions. The one function in this library will be called max and will call the max method of the com.sitepoint.jsp.Functions class.

To use this library in our JSP, we need to add a @taglib directive for it to the top of the page:

<%@ taglib prefix="spfn" uri="http://www.sitepoint.com/jsp/taglibs/functions" %>

We can now calculate the size attribute of our

Next up in our Java display logic, we have a while loop that iterates through the to-do list items, pulling each out in turn to be processed:

        <%      

        while (it.hasNext()) {      

          ToDoItem toDoItem = (ToDoItem) it.next();      

          %>

This is almost shamefully simple to do with JSTL’s tag:

Again, we’re using the simple EL expression ${toDoItems} to access the request attribute supplied by the controller. This tag will output its contents once for each item in the list, assigning that item to the EL variable name specified by the var attribute (toDoItem, in this case).

Our final tidbits of Java display logic are used to output the ID and text of the ToDoItem objects contained in the list:

Here’s where EL really comes into its own. In addition to simplifying drastically the process of pulling values out of request attributes, it’s also really good at pulling values out of those values! Let me show you what I mean…

Although I didn’t mention it at the time, the ToDoItem class was designed according to the JavaBeans standard. Though it has some more complicated sections, the JavaBeans specification (not to be confused with Enterprise JavaBeans — a completely different spec) is mainly just a naming convention for classes and methods.

Under the JavaBeans spec, if an object has a property (a value that can be read and written), then it should have getPropertyName and setPropertyName methods to access it. If it’s a read-only property, then it should only have a getPropertyName method. If the property contains a boolean value, then the ‘get’ method should be called isPropertyName instead.

There’s a lot more to the spec than that, but those are the bare essentials. Since the ToDoItem class has a getId method, it has a read-only property named id.

The point of all this is that EL is JavaBeans-savvy: EL makes it really easy to get values of JavaBean properties. So, to output the value of a ToDoItem‘s id property, we can use this expression:

${toDoItem.id}

As for the text value of the ToDoItem, EL will automatically convert any object to a String using its toString method, so we could just use ${toDoItem}. Our Java code, however, also uses the HTMLEscaper class to escape any characters that might be interpreted as HTML code. But wait: JSTL/EL can do that, too!

Actually, there are two ways to escape HTML special characters with JSTL/EL. The first is to use the JSTL tag with the escapeXml attribute:

Even more convenient is the EL function fn:escapeXml:

${fn:escapeXml(toDoItem)}

Here’s how to output our to-do list items in our new todo.jsp file:

Since we’re no longer using the HTMLEscaper class, we can remove the relevant files from our web application. We can also remove the @page directive that imported this and the other classes that were used by our Java display logic code: no Java code, no imports needed!

With all those changes made, our finished todo.jsp file looks like this:

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>      

<%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions" %>      

<%@ taglib prefix="spfn" uri="http://www.sitepoint.com/jsp/taglibs/functions" %>      


    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">      

      

      

  To-Do List      

  
      content="text/html; charset=iso-8859-1" />      

  
      href="" />      

      

      

        

    " method="post">      

            

            

          

        

  " method="post">

Though certainly new, the JSTL/EL syntax in this file will be a lot easier for your average web designer to grasp than the Java code that was there previously!

Here’s the file and directory structure of our updated application:

/todo.jsp      

/styles.css      

/WEB-INF/functions.tld      

/WEB-INF/web.xml      

/WEB-INF/classes/com/sitepoint/AddToDoServlet.class      

/WEB-INF/classes/com/sitepoint/AddToDoServlet.java      

/WEB-INF/classes/com/sitepoint/DeleteToDoServlet.class      

/WEB-INF/classes/com/sitepoint/DeleteToDoServlet.java      

/WEB-INF/classes/com/sitepoint/ToDoItem.class      

/WEB-INF/classes/com/sitepoint/ToDoItem.java      

/WEB-INF/classes/com/sitepoint/ToDoList.class      

/WEB-INF/classes/com/sitepoint/ToDoList.java      

/WEB-INF/classes/com/sitepoint/ToDoServlet.class      

/WEB-INF/classes/com/sitepoint/ToDoServlet.java      

/WEB-INF/classes/com/sitepoint/jsp/Functions.class      

/WEB-INF/classes/com/sitepoint/jsp/Functions.java      

/WEB-INF/lib/jstl.jar      

/WEB-INF/lib/mysql-connector-java-version-bin.jar      

/WEB-INF/lib/standard.jar

Download the code. (759KB)

As far as JSP best practices go, this updated to-do list example is about as good as you’re gonna get by following the official specs. And, admittedly, we’ve got a pretty powerful web application platform happening here. You could certainly build sizeable applications using nothing but Java classes for the model, Java servlets for the controller, and JSPs using JSTL/EL for the view, but there are more powerful options out there.

Instead of hand-coding database access in your model classes, you can use a persistence framework to synchronize your database with a set of auto-generated Java objects automatically. Hibernate is the darling of the day in this area, though EJB 3.0 is on the horizon with all the same benefits in a standardized package.

Instead of writing all of your application logic as a twisty set of servlets, you can use a web application framework like Struts, WebWork, Tapestry or Stripes to manage the complexity.

Instead of relying on JSTL tags and EL expressions enhanced with your own custom functions, you can use other tag libraries like JavaServer Faces or one of the many open source taglibs, or you can step away from JSP and use a templating system like Velocity or XMLC.

You could almost say that there are more ways to build web applications with Java than without it! Be sure to follow The Daily Grind, SitePoint’s Java blog, as I explore these many options, and watch sitepoint.com for more articles to help you discover the joys of Java web development.