Tapestry Training -- From The Source

Sunday, September 21, 2008

Tapestry version 5.0.15 has been released. The good news is that this is the final beta. The bad news is that it was supposed to be the release candidate. After the release was created, and during the voting period, a couple of annoyances (mostly for non-English applications) were identified. Rather than postpone the release further, it was decided to continue with the release and have one more release as the release candidate (and likely final release).

Anyway, outside of these minor issues, this release is ready for prime time, with some significant improvements to client-side behavior and Ajax support, more localizations, improvements to the IoC container, and the solution to a significant deadlocking problem.

Meanwhile, I'm in London now after a very successful talk on Tapestry at JavaZone in Oslo. My goal for those sessions is shock and awe with a dash of humor, and I'm told I delivered, to nearly 100 attendees. Suzy was in the audience, as was Eitan Suez, James Ward and Scott Davis.

This week is Tapestry 5 training in London, and next week Haarlem (in Amsterdam). I get back to the US in October, and that's when we'll get the final Tapestry 5.0 release out the door ... and I'm already working on 5.1 in a branch.

Sunday, September 14, 2008

The vote to release Tapestry version 5.0.15 is under way. This is the release candidate. Once it's available, we'll give it a few weeks of exposure (while I'm in Europe) and then, barring any unforeseen critical bugs, we will vote it up as the 5.0 GA release.

I already have extensive plans for improvements to Tapestry in 5.1. I want one of the compelling reasons to use Tapestry to be performance, so I'm looking at automatically GZIPing content, compressing JavaScript (and perhaps combining JavaScript files together), making increased use of far-future expired headers and so forth. In other words, just make the framework do the right thing.

I think there's also room to optimize the server-side further. I have some ideas for limiting the number of render commands needed to render a page, and limit the amount of work wasted on event notifications that have no listener.

Saturday, September 13, 2008

Just found a
short article by Moataz Anany, detailing his search for a good Java web framework ... and how he's taken to Tapestry. He identifies some of the strengths and a few of the weaknesses of Tapestry.

Just a bit bored, redoing the Tapestry 5.0.15 build. Surfing the web during the build, and found Robert Heinlein's all purpose FAQ.

Science Fiction: Stories that would cease to exist if elements involving science or technology were omitted.

This puts Star Trek and Star Wars where they both belong: in fantasy. You could "swap out" phasers for guns, light sabers for magic swords, aliens for demons, planets for foreign cities or countries, and space ships for traditional transportation and not really change the Star Wars story, or most Star Trek episodes, at all. I tend to call this "Sci Fantasy"; most older Space Opera falls into this space as well.

Cryptonomicon and the Baroque Cycle are very firmly in SF however, since both stories are driven by science and technology and even the philosophy of science and technology (and the personalities behind those who invent science and technology).

My thought here is that the movies and television, which nominally have a large bandwidth of information, are actually too narrow to portray science fiction properly. Novels and even short stories, because they can more naturally go inside people's heads and reveal their thoughts, are much more adept at capturing what makes Science Fiction about science and not fantasy. But, of course, it's always on a spectrum ... virtually any story that places actual humans on distant planets beyond the solar system is implausible to a point that borders on fantasy, even if faster-than-light travel is avoided.

Thursday, September 11, 2008

In the previous article, I discussed the basics of Tapestry 5 IoC. I focused on the terseness of Tapestry's container, even though everything occurs in Java code. I alluded to special features of Tapestry 5 IoC, service configurations. Let's start investigating those.

In traditional dependency injection, the relationship between a service and its dependencies is many-to-one: many services may
inject a specific dependency. Whether that dependency is selected just by service type, or by service id, or by some other mechanism, it's still one single object.

Service configurations are somewhat inverted: they are a relationship from one service to many objects. The objects, or contributions, may be simple objects or may themselves be services.

Let's use a specific example from Tapestry to put this into perspective. Previously I showed
the service builder method for the TranslatorSource service:

Let's dive a little deeper and look at what this service does. It's a source for
Translator objects, which are an integral part of Tapestry's HTML form support. Translators are responsible for converting between server-side values (such as numbers, dates, and so forth) and client-side strings. They also play a role in client-side validation of user input.

Tapestry matches up properties that are edited by TextFields with corresponding Translator instances. This all happens inside the TextField component and is largely invisible to programmers. In any case, the TranslatorSource service is central:

public interface TranslatorSource
{
/**
* Returns the translator with the given logical name.
*
* @param name name of translator (as configured)
* @return the shared translator instance
* @throws RuntimeException if no translator is configured for the provided name
*/
Translator get(String name);
/**
* Finds a {@link Translator} that is appropriate to the given type, which is usually obtained via {@link
* org.apache.tapestry5.Binding#getBindingType()}. Performs an inheritanced-based search for the best match.
*
* @param valueType the type of value for which a default translator is needed
* @return the matching translator, or null if no match can be found
*/
Translator findByType(Class valueType);
/**
* Finds a {@link Translator} that is appropriate to the given type, which is usually obtained via {@link
* org.apache.tapestry5.Binding#getBindingType()}. Performs an inheritanced-based search for the best match.
*
* @param valueType the type of value for which a default translator is needed
* @return the matching translator
* @throws IllegalArgumentException if no known validator matches the provided type
*/
Translator getByType(Class valueType);
}

Here's where it gets interesting

So, what Translators are built into Tapestry? You might think you could tell by looking at the implementation of the service:

But you don't see any pre-defined Translator instances here ... just Collection<Translator> configuration passed
to the constructor. Each Translator provides its name, and those all go into the translators map ... but the question is, where do they come from?

It's looking pretty likely that Tapestry supports string, byte, integer, long, float, double and short out of the box.
The naming of this method is another example of convention over configuration. The prefix this time is
contribute and the rest of the method name matches the service id, TranslatorSource.

So, Tapestry has invoked the contributeTranslatorSource() method, collected up the objects, the Translators, added to the configuration object, and converted the configuration object to
a Collection, which is ultimately passed to the TranslatorSourceImpl constructor.

Seems awfully complicated, doesn't it? Well, it is nice (from a testing perspective) that TranslatorSourceImpl isn't tied
to any particular implementations of Translator. But that's not the real benefit.

The real benefit, and this is the basis of the entire concept, is that you are not locked into just these Translators. You can define your own, and mix them in with the ones supplied by Tapestry. And you don't have to hack TapestryModule or TranslatorSourceImpl to do it.

Say your application defines a Currency class, to track currency amounts of orders and payments. That might be handy to use instead of double, for accuracy reasons. You might also want to parse and format currency values differently than naked doubles ... for example, to require exactly two digits of precision, or to ignore a leading dollar sign.

To mix in your own Translators, all you need to do is define your own module:

This translator, CurrencyTranslator, will be indistinguishable from the default set of Translators provided by Tapestry; TranslatorSourceImpl will have no way of telling which Translators came from where. Your contributions are on an even footing with those provided by Tapestry itself.

You might ask in what order are these contribute methods are invoked? The answer is: Who knows? That's why the configuration is passed to the service implementation as (unordered) Collection, not (ordered) List. As we'll see in the next article, Tapestry has alternatives for when you care about ordering, or when you want your configuration in the form of a Map.

When are these methods called? They are called when the TranslatorSource service is realized, which happens when a method of the service is first invoked. Tapestry IoC is by default very lazy, it doesn't instantiate services until necessary. The service's proxy is responsible for this realization process, and its done in a thread-safe manner.

Dealing with this kind of loose binding in a structured manner is very helpful: it means that the TranslatorSource service is simplified: it doesn't need a method to add a new Translator, there's fewer issues related to multiple threads, and the available set of Translators never changes, which makes the behavior of the service much more predictable.

Conclusion

We've only just pierced the surface of Tapestry configurations, but we're beginning to see what I mean when talk about Tapestry's extensibility. Much of the key behavior of Tapestry is specified in terms of this kind of configuration, or one of its close relatives. And, as the example showed, building a service that uses a configuration is just a matter of defining a parameter of type Collection in the service's constructor.

In future articles, I'll discuss other variations of service configurations, and show how to go meta with Tapestry by leveraging configurations in combination with service-building services!

Monday, September 08, 2008

Apparent, closures are coming for C and Objective-C. Objective-C was my first OO programming language, and the transition to Java was a painful one. For a long time, I couldn't go back because Objective-C was not garbage collected (this has changed). Then I couldn't go back because it didn't have closures (or even closures' red headed step child: the inner class).

I haven't updated my project dependencies in a bit since upgrading from IntelliJ 7.0.3 to 7.0.4. I was pleasantly surprised after updating my POM dependencies that the Maven support has improved. In the past, the Maven support had a tendency to select less than ideal values for each module's source paths ... and it would overwrite my customizations every time I did a sync. I had come to dread changing dependencies because of this.

In 7.0.4 I had to refresh my Maven projects list; this took a few minutes. But lo and behold; it did a perfect job, not altering my personal changes. Bravo!

Sunday, September 07, 2008

Just rounding out the last few important bug fixes (and enhancements) that are needed for the Tapestry 5 release candidate. Can I get it together before I leave for my Europe trip on Sept. 15th? If not, the RC may wait until October.

If you find yourself doing something tricky with threads, such as rooting out some insidious thread deadlocks, jconsole is invaluable. Having it analyze the threads to get the deadlocks is awesome, and the stack trace even includes identifiers about what object monitors have been locked. Way better than sorting through all that, by hand, from a text stack dump.

So, here I am, in the middle of some intense debugging related to the dreaded combination of threads, class loaders and deadlocks and suddenly ... my integration tests no longer run!

Ultimately, my changes were very modest (a little bit of extra synchronization against the context class loader), so what gives?

Well, if your tests are like mine, and run against Firefox, your issue might be that Selenium is unable to start up Firefox if an upgrade has occurred, especially if the Firefox upgrade is not compatible with your plugins.

The solution? Start Firefox manually, to get through the dialogs it presents. Then rerun your tests.