Screencast #5: Grid Component

The latest Tapestry 5 Screencast is now ready; this one clocks in at almost 11 minutes, and shows me forgetting parameter names and such as I set up a grid with my good ole' fallback: iTunes music data. I actually made a couple of mistakes on purpose to show off the exception reporting (that's only gotten better since 5.0.2, the base line for this screencast).

I think this shows off how quickly and easily you can pull data out of a service and up on the screen. To borrow a phrase: "I don't have time for drag and drop!"

One minor mistake was that I didn't map the context correctly (I had cut-n-pasted an existing launch configuration); thus all the URLs are prefixed with "hilo/" rather than, say, "musiclib/". Oh well. Oops, and I forgot to hide the dock!

Maven Archetype for Tapestry 4

Sure, Webtide did it first, but it seems like Josh Long may have done it better: Tapestry 4 Maven Archetype.

Tapestry 5.0.2 released

A new preview release, Tapestry 5.0.2 is now available. It fixes a number of bugs and adds a number of features (including line precise exception reporting, and sortable Grid columns). Along the way, I found out some important deployment notes about Tomcat (and JBoss).

The new release is available via the central Maven repository, or via direct download.

Tapestry 5 and Groovy

I was curious just how well T5 and Groovy would work together, so I took an existing application, enabled Groovy for it (using the Eclipse plugin) and added a Groove page to my existing application:

package org.example.hilo.pages;

class Holder
{
  String firstName;
  String lastName;
  int age;
}

class Groove {

 def message()
 {
   "Get your Groove on, Baby!"
 }
 
 def onAction()
 {
  println "onAction invoked"
 }
 
 def items()
 {
   [ new Holder(firstName: "Howard", lastName:"Lewis Ship", age:40), new Holder(firstName: "Scott", lastName: "Simon", age:42) ]
 }
}

Guess what? It just worked, no problems. I generated a Grid with the two Holder items, my onAction() method is invocable, and I can retrieve the message. It is just bytecode under the covers.

Alas, without some kind of annotation support, there's no way to mark a field as persistent, so there's tremendous limits on what can be accomplished right now. I've heard rumors that some kind of JDK annotation support is forthcoming; failing that, I've thought about an additional file, read at runtime, that would provide class, method and field annotations. But I'd rather someone else does it.

In addition, Tapestry is reading the compiled .class file; I haven't even thought about trying to get things to work from uncompiled .groovy files and I can imagine there may be some class loader headaches there.

Still, for five minutes effort, it was nice. And I really think I could come to really like the streamlined, sensible syntax ... and for god's sake, first class closures!

Updated Tapestry Tutorial

I've updated the Tapestry 5 Tutorial, adding chapter 3, which is about the basics (including ActionLink). I may need to trim down some of the theoreticals, it's a bit verbose.

Tapestry 5.0.2 is ready to be announced on monday; one of the last things in was a renewed Exception Report page, including the return of line precise exception reporting. I've gotten better at design layout & CSS (though still pretty lame) but the results are looking good (you can seen a screenshot of the exception report page in the tutorial).

T5 coming together rapidly

A long day today, fixing bugs, adding missing features, and otherwise getting things ready for another preview release, 5.0.2. I just re-implemented the support for line precise exception reporting (the part that shows the content of the file in error) and, with a bunch of new CSS tricks up my sleeve, it looks better than ever. At least, on Firefox it does. Somehow I'm sure the ExceptionReport page will pop up when I do the next screencast.

I also added a lot of documentation on page navigation in Tapestry 5, finally documenting exactly what event handler method return values are meaningful, and what behavior they trigger. Of course, that's extensible via service configuration contributions.

I've got many more things on my plate: there seems to be an issue with localization, at least according to one Chinese (or at least, Asian) user. I need to get cracking on nicely integrated JavaScript. I need to support dates with a date translator and some date validators. Lots of stuff related to Ajax, especially the intersection of Ajax and form support. Well, just plain lots and lots more. Joy.

See you at JavaOne!

My Birds of a Feather session, "Tapestry 5: Java Programming Language Power, Scripting Ease" is in for JavaOne. No details on when and where (I predict someplace dank and dark, and late at night when all the good parties are going) but still, it's good to get the nod this year, given how competitive it is.

I promised Ajax features and live demos; I haven't written the Ajax stuff yet, but the live demos will be cake with Tapestry 5.

Hope to see everyone there!

Fighting with Tomcat

It all started innocently enough, TAPESTRY-1287: Tapestry does not deploy properly under JBoss 4.0. Just a simple security or configuration problem, no biggie I thought.

Turns out, its not JBoss at all, it's Tomcat 5.5.20.

Tapestry 5 relies on a feature of class loaders: If you invoke ClassLoader.getResources() with a folder path, it returns the URLs of the folders. Sometimes this URL is for a file on the filesystem, and if you open the connection you get a series of lines identifying the files and sub-folders. Other times, the URL is for a JAR and you get a JARURLConnection and ultimately a JarFile instance.

Tapestry uses this information to scan the classpath, including the WAR, for all page and component classes. This is the key part of the case insensitivity feature.

This works great under Jetty and I didn't give it a second thought until this bug popped up.

Alas, Tomcat works very differently. It partially explodes the WAR on deployment, but doesn't extract the classes to WEB-INF/classes. It also doesn't do what Jetty and the JVM's ClassLoaders do, in terms of responding sensibly to folder paths (as discussed above).

That leaves Tapestry 5 out in the cold, because it can't locate any of the web application's pages, either via the supported approach, ServletContext.getResourcePaths(), or via the ClassLoader approach (which is not documented but completely reasonable).

Tapestry isn't the first one to hit the kind of problem; a recent JBoss bug, JBAS-2676 shows that the Facelets crew hit a similar problem, and I've added Bug 41664 to ASF's Bugzilla to see if I can get a response.

So, I'm starting to dig around, to see if there's any magic I can use to kludge together a workaround. I've been hunting around in the debugger, trying to find some object that has a reference to the original WAR, which I could open up and read, just to scan WEB-INF/classes.

If that doesn't come together soon, I'll need a different approach, such as a Maven task to locate the classes and add some kind of index file to the WAR that can be used at runtime. I've really been trying to avoid doing anything that requires anything special during build and deploy, I want everything to just work ... and Tomcat is letting me down!

Blog comments disabled temporarily

I've had to cancel blog comments for a little bit, until the current wave of comment spammers "play through".

T5: Component Reference Documentation

Had a frustrating weekend struggling with Maven (those people are sadists) and with Javadoc (just plain idiots), but the end result is a Maven report plugin to generate component reference documentation.

Here's a sample, for tapestry-core.

Now, this is just the reference documentation, equivalent to JavaDoc: a starting point for real documentation. But it is generated right off the source files (via a JavaDoc doclet) so it is always automatically up to date.

T5 Screencast #4: BeanEditForm

Just finished a new screencast on BeanEditForm: Tapestry 5 Screencast #4.

In twelve minutes (including some lovely fumbling around the 8 minute mark), I only scratch the surface of what BeanEditForm can do, and it's still not quite as powerful as Daniel Gredler's BeanForm component for Tapestry 4 ... but it is easy and fast and full of fun tricks.

Introducing this component first, and only incidentally talking about Label and TextField, is according to plan. I want people to get hooked on Tapestry 5's power and ease of use immediately.

Next up: the Grid component.

Direct Component Rendering in T5

One question that pops up in the T4 mailing lists quite often is "How do I render a PDF?" (or a chart, or an Excel spreadsheet, etc.).

In T4, this takes a bit of care and planning: a new engine service to represent the resource to be generated, perhaps a new Asset implementation that references the service. The necessary HiveMind configuration to add the engine service to the mix, and perhaps give it a friendly URL mapping. Perhaps a touch of web.xml for that last bit as well.

In Tapestry 5, there's an interface, StreamResponse, that may be used as the return value from an component event handler method. StreamResponse encapsulates a MIME content type, and an InputStream that will be read and pumped down to the client.

And that's really all it takes. Here's an example from the test suite:

public class Start
{
    Object onActionFromTextStreamResponse()
    {
        String text = "<html><body>Success!</body></html>";

        return new TextStreamResponse("text/html", text);
    }
}

This method is invoked when the corresponding component's link is clicked; from the template:

<a t:type="ActionLink" t:id="textStreamResponse">Text Stream Response</a>

This is just an event handler method; normally these return a page name or a page instance, and a client redirect is sent to get that page to render. By returning a StreamResponse, it is the stream response that is returned to the client (immediately, in the same request; there's no redirect).

That's the point of T5: Simple things should be easy.

More Tapestry 5: Grid Component, Case Insensitivity

I've been busy building a Grid component to replace T4's contrib:Table component. It's coming out great, I can't wait to put up a screen cast of it soon (once I get sorting working). It has a clean UI (more default CSS), uses a Digg-style pager, at the bottom, and it's scary fast.

Better yet, its pretty automatic. If you pass the Grid a list of components, it builds its model from the first component (it expects them to be uniform). The model even understands the order of properties, based on the order of the getter methods within the bean class. It uses similar concepts to the BeanEditor to create default labels and so forth. Basically, it's zero configuration ... push a list of objects at it, and it will build the entire UI, column labels, column order ... the whole enchilada.

Meanwhile, I've been working under the covers to further extend the bounds of case insensitivity. It's now a hard-wired concept inside Tapestry IOC, which provides a CaseInsensitiveMap (a full java.util.Map where the keys are case insensitive) to properly support it. I'll be able to strip out a whole lot of string.toLowerCase() calls inside tapestry-core (I'm just taking a little break now). Back to the point ... now when you are injecting, contributing, or doing anything else with Tapestry IOC the case of the ids just don't matter anymore. One less thing to worry about while developing (no more "is that 'Checkbox' or 'CheckBox'?").

I showed off some Tapestry 5 to my friends at Formos and they loved every bit of it. Here's a company that develops exclusively in Tapestry, and has concurrent projects in Tapestry 3 and Tapestry 4 and they loved every bit of it. Many of my "innovations" were similar to things they extended Tapestry to do for their applications, but they appreciated the idea that it is baked into Tapestry itself. And there's a few other ideas I've had that haven't occured to anyone else yet.

It was very gratifying to see how excited they got by Tapestry IOC. "It's HiveMind -- without the XML, come check it out!". So it's nice to get a little confirmation that things are on the right track.