Mac/PC Parody Ads

Tip of the hat to Ted Neward for pointing these out: Parodies of the "I'm a Mac/I'm a PC" ads.

New Screencast: Tapestry Maven Archetype

I've added a new screencast, this one showing off the use of the tapestry-simple Maven archetype to create a new project. It runs about five minutes and shows off how simple it is to get up and running.

If you haven't built Tapestry 5 locally, you need to remember to add -DremoteRepositories=http://people.apache.org/repo/m2-snapshot-repository/ to the command line.

I'm thinking about starting a vote to do a preview release of Tapestry 5, just to get the necessary JARs and archetypes into the general Maven repository.

Tapestry 5: Caseless URLs

Big improvements to Tapestry 5 URLs today. Whereas Tapestry 4 had "friendly URLs" (friendly to what? Mostly to search engines), Tapestry 5 has "pretty URLs" that look much more like their hand-tooled brethrern.

The news today is that the pretty URLs are now case-insensitive. Well, that's a slight exaggeration; the portion of the URL that specifies the name of the page and the component id within the page is now case insensitive. Thus http://localhost:8080/login.form.action is exactly the same, to Tapestry, as http://localhost:8080/LOGIN.FORM.ACTION¹. The first form, all lower case, is what's generated by Tapestry by default.

Under Tapestry 5, there are really two main types of URLs: component event URLs and page render URLs. Page render URLs are now just the name of the page, i.e., http://localhost:8080/login ... there's no longer an extension tacked on. Submitting forms, or clicking component action links, does some processing and sends back a page render URL, so what you see in the browser's address bar is always a bookmarkable, short, relatively opaque URL.

In some cases, a page will have a "passified context" which is just a very generic way of saying, "the primary key for the entity this page displays". Thus you might have a ViewPerson page that uses some kind of numeric id as its context. The URL ends up being http://localhost:8080/viewperson/99. In other words, the URLs Tapestry is generating end up looking pretty much exactly like what you'd create in a hand-tooled application. And all of this with zero configuration. It just works.

¹As I typed this, I realized that the last part of the URL, ".action", which is the component event name, is not currently case insensitive, something I'll address tormorrow.

Tapestry 5 Maven Archetype

I've just put together a rather decent Maven Archetype for Tapestry 5. It's called "tapestry-simple" and its documented here.

The archetype allows you to create a Tapestry 5 application in, literally, seconds. It generates the pom.xml (for Maven), .classpath/.project (for Eclipse), as well as web.xml, log4j.properties, the complete directory structure, even a sample Start.html and Start.java.

It also configures the Jetty plugin so that you can immediately run the application using "mvn jetty:run".

This took only a little doing. The Maven documentation was awful as usual (yes, kettle, stove, etc.), but peeking at a couple of the sample archetypes, and trying some experiments, allowed me to put together something relatively complete and polished in a couple of hours. And those hours will save thousands of developers an hour or two each.

To make this work, you need to edit your settings.xml to add in the Apache snapshot repository at http://people.apache.org/repo/m2-snapshot-repository/ ... but perhaps better (and almost as easy) is to check out the latest Tapestry 5 source from SVN and build locally. You'll want the tapestry-project, tapestry-ioc, tapestry-core and tapestry-simple projects. Do a "mvn clean install" and all the latest and greatest will be in your local Maven repository!

1.0.0 releases for tapestry-prop, -flash, -spring

I've gotten no negative feedback on the main three libraries at Tapestry @ JavaForge so it's time for a 1.0.0 release for all three:

• tapestry-spring - Tapestry/Spring integration
• tapestry-prop - Highly efficient property access, used instead of OGNL in many palces
• tapestry-flash - Temporary storage of data until the next request (often used for redirect-after-post messages)

The files are all available from my Maven 2 repository: http://howardlewisship.com/repository/. If you aren't a Maven user, the binary and source distribution are available at http://howardlewisship.com/downloads/tapestry-javaforge/.

Note that all of these are compiled against Tapestry 4.0.2, the latest stable release of Tapestry. Once Tapestry 4.1 has a stable release, I'll bump the version numbers and update the dependency.

Proposal for new property operator

There's been a few blog postings about adding property support to the Java language properly. Here's a synopsis. The goal is to make it easier to access object properties, using property names, rather than method names.

I'm amazed at some people's ability to Not Get It.

The proposal is too add a special operator, ->, for this purpose.

This means that you have to be aware that something is a property before you know how to access it.

Properties in other languages are powerful because they are accessed just like fields. You see this in Ruby especially. You can change your mind and switch from simple public instance variables to getter/setter methods at any time, without breaking any existing code. Ruby will even generate the getter and setter for you. Braindead simple.

So, Mr. Danny Coward, here's a proposal for you. I would like the property access operator to be ..

Let me make that more clear: .

You know, the exact operator used in other languages, the exact operator that anyone would expect.

Let the compiler do the work. The -> operator is an approach to make the compiler do less work and the developer do more. That is ass-backwards. I'm slaying dragons over here in Tapestry 5 land, to make the environment bend over backwards to adapt to the user, easily and seamlessly. It would be nice if the overlords in charge of the Java language would take that as their lesson. Complexity is not solved by adding more complexity. Complexity is solved by removing complexity ... even if it requires a bit more work behind the scenes to support that simplicity.

Of course, this may all be a distraction from their main attemmpt to screw the pooch: super modules. More on that soon.

Latest T5 Snapshots: Invisible Instrumentation

I just uploaded the latest T5 snapshots. I did some work on the template parser; you now have an alternate template syntax, more like Tapestry 4:

<span t:id="foo" t:type="Bar" param="literal-string"/>

In Tapestry 4, it would be the same, except jwcid="foo@Bar".

I'm struggling with what's the correct binding prefix? With <t:comp> the default binding prefix is "prop:", meaning a property name or property path unless an explicit prefix is given.

With invisibly instrumented elements, the expectation is that more of the parameters will be fixed string literals, so the default binding prefix is "literal:". Thus you might have to do the following:

<input type="text" t:id="userName" t:type="TextField" value="prop:userName" validate="validate:required"/>

However, there's some implemented and upcoming improvements that will shorten and simplify this snippet.

Notice that the t:id and value attributes are pretty much the same? That's a Dont Repeat Yourself violation; Tapestry 5 already handles this particular case: if the value parameter is omitted, it is assumed to match a property of the container with same name as the component's id. This is already implemented. So the example is reduced to:

<input type="text" t:id="userName" t:type="TextField" validate="validate:required"/>

The remaining ideas are not yet implemented.

We've put <input type="text"> into the template for preview purposes. Tapestry should be able to deduce that we want a TextField component. That reduces the example to:

<input type="text" t:id="userName" validate="validate:required"/>

The final change refers to the validate parameter. It's type is FieldValidator, not string ... that's why we're invoking the "validate:" binding factory to convert the string ("required") into a FieldVaidator instance. I'm not sure what this would look like (either special code on the TextField component, or some additional logic to invoke the ValidateBindingFactory), but it seems to me we should be able to remove the "validate:" portion:

<input type="text" t:id="userName" validate="required"/>

This is part of the goal of Tapestry, that whether you're writing templates or Java code, you should only write the bare minimum that's necessary, and Tapestry should be able to fill in the gaps. That's partly convention over configuration, but the overall concept goes deeper than that.

This last bit, omitting the need for explicit binding prefixes, was a battle I lost in the Tapestry 4 time frame, but the approach I was taking then was more involved; a default binding prefix for each parameter. I just want Tapestry to realize that I supplied a simple string, but the component needs a FieldValidator, and that those come from athe ValidatorBindingFactory service. Tapestry should be able to close the loop on that without generating any surprises.

HiveDoc for Maven 2

Marcus Schulte has put together a Maven 2 plugin for HiveDoc. It generates very good hypertext documentation, with a better layout than than the built-in documentation and well integrated into the overall Maven site. An example of the generated documentation comes from the honeycomb project (which is one of the Hibernate integration modules available for HiveMind and Tapestry). Happy New Year, Marcus ... and thanks!