Tapestry Training -- From The Source

Let me help you get your team up to speed in Tapestry ... fast. Visit howardlewisship.com for details on training, mentoring and support!

Wednesday, September 27, 2006

Very handy Regular Expression Tool: QuickREx

I was puzzling out how to do some text processing in Tapestry and it came down to some regular expressions. Now, I use these all the time, but I'm not hyper literate in them ... I always need to test them out before I feel confident in them. I had been using an Eclipse plugin for this that went payware, so for I while I was firing up IRB (interactive Ruby).

Fortunately, during a quick thinking break, I decided to see if there was a new Eclipse tool for this ... and there is QuickREx.

It does a very good job ... it allows you to write your regular expression, provide it with sample text, and view matches and groups within matches very nicely. You can set options (such as multiline or caseless) and it even can run for all the major different RE implementations out there (JDK, ORO Perl, ORO Awk, and JRegex). It does live evaluation, which really helps when trying to "tweak" the expression, and has a bunch of other well thought out features, such as helping you to paste the final expression into Java code (escaping the backslashes, and such, for you).

The expression editor includes completion; hitting ctrl-space brings up a menu of different regular expression codes to insert, each with a snippet of documentation. Nice.

The plugin also includes a secondary view, the Regular Expression Library. This contains a library of regular expressions, each with example text to match against and a chunk of documentation.

In fact, there's a few more features that are hard to explain out of context, but I suspect will prove quite useful. This is another example of a finely crafted tool created not as a demonstration of someone's Eclipse plugin coding chops, but created to be used.

Easy install via the update manager http://www.bastian-bergerhoff.com/eclipse/features) and it's run flawlessly since.

Tuesday, September 26, 2006

More Tapestry / Hibernate Integration: Honeycomb

Honeycomb is another integration between Tapestry and Hibernate. What's neat is that it supports Session Per Conversation (somewhat like Seam) and Session Per Request (much more common) right out of the box.

It even includes Maven archetypes to get the project set up quickly. Nice.

Once again, the power of HiveMind is evident here; just placing the Honeycomb JARs on the classpath mixes all the Honeycomb support directly into the application. No additional configuration needed.

On the other hand, there's virtually no documentation on how to use Honeycomb beyond the Javadoc ... and some of that is in German!

Monday, September 25, 2006

Javassist vs. Every Other Bytecode Library Out There

I've been getting a small amount of flack about Tapestry and HiveMind's use of Javassist. Yes, its inside the evil JBoss camp. Yes, it has a wierd MPL/LGPL dual license. Yes, the documentation is an abomination. Yes, the API is so ugly that I always craft an insulation layer on top of it. Yes, there are are other bytecode toolkits out there. So why am I so wedded to Javassist?

Because it's so damn powerful and expressive.

A lot of the magic in HiveMind and Tapestry 4 is due to Javassist, and Tapestry 5 is even more wedded to it.

Much of what HiveMind does could be done using JDK dynamic proxies. HiveMind uses proxies to defer creation of services until just needed ... you invoke a method on the proxy and it will go create the real object and re-invoke the method on that real service object. You code never has to worry about whether the service exists yet or not, it simply gets created as needed.

You can do things like that using JDK proxies, but proxies are not going to be as optimized by Hotspot as real Java classes. The core of dynamic proxies is to use reflection, each method invocation on the proxy turns into a reflective method invocation by the proxy's handler. There's further overhead creating an array of objects to store the parameters.

Simple proxies like that can certainly be written using other toolkits like ASM.

Because these proxies are so common in Tapestry 5, my insulation layer can build the whole proxy as a single call; the insulation layer translates this to Javassist API:

    public void proxyMethodsToDelegate(Class serviceInterface, String delegateExpression,
            String toString)
    {
        addInterface(serviceInterface);

        MethodIterator mi = new MethodIterator(serviceInterface);

        while (mi.hasNext())
        {
            MethodSignature sig = mi.next();

            String body = format("return ($r) %s.%s($$);", delegateExpression, sig.getName());

            addMethod(Modifier.PUBLIC, sig, body);
        }

        if (!mi.getToString())
            addToString(toString);
    }

Here, delegate expression is the name of the variable to read, or the name of the method to execute, that provides a proxy. The only real part of this code that is Javassist is that code snippet: return ($r) %s.%s($$);. The first %s is the delegate expression; the second is the name of the method. Thus this may be something like: return ($r) _delegate.performOperation($$); Javassist has a special cast, ($r) that says “cast to the method's return type, possibly void”. It will unwrap boxed values to primitives, as necessary. The $$ means “pass the list of parameters to the method”.

Thus we can see how quickly we can build up new methods that invoke corresponding methods on some other object.

In Tapestry 5, the real workhorse is the ClassTransformation system which is used, with Javassist, to transform classes as they are loaded into memory. This is how Tapestry 5 hooks into the fields of your class to perform injections and state management. Tapestry 4 did the same thing using abstract properties and a runtime concrete subclass … this is much more pleasant.

Some of the trickiest code relates to component parameters; there are runtime decisions to be made based on whether the parameter is or is not bound, and whether the component is or is not currently rendering, and whether caching is or is not enabled for the parameter. Here’s just part of that logic, as related to reading a parameter.

    private void addReaderMethod(String fieldName, String cachedFieldName,
            String invariantFieldName, boolean cache, String parameterName, String fieldType,
            String resourcesFieldName, ClassTransformation transformation)
    {
        BodyBuilder builder = new BodyBuilder();
        builder.begin();

        builder.addln(
                "if (%s || ! %s.isLoaded() || ! %<s.isBound(\"%s\")) return %s;",
                cachedFieldName,
                resourcesFieldName,
                parameterName,
                fieldName);

        String cast = TransformUtils.getWrapperTypeName(fieldType);

        builder.addln(
                "%s result = ($r) ((%s) %s.readParameter(\"%s\", $type));",
                fieldType,
                cast,
                resourcesFieldName,
                parameterName);

        builder.add("if (%s", invariantFieldName);

        if (cache)
            builder.add(" || %s.isRendering()", resourcesFieldName);

        builder.addln(")");
        builder.begin();
        builder.addln("%s = result;", fieldName);
        builder.addln("%s = true;", cachedFieldName);
        builder.end();

        builder.addln("return result;");
        builder.end();

        String methodName = transformation.newMemberName("_read_parameter_" + parameterName);

        MethodSignature signature = new MethodSignature(Modifier.PRIVATE, fieldType, methodName,
                null, null);

        transformation.addMethod(signature, builder.toString());

        transformation.replaceReadAccess(fieldName, methodName);
    }

That last line, "replaceReadAccess", is also key: it finds every place in the class where existing code read the field, and replaces it with an invocation of the method that contains all the parameter reading logic … a method that was just dynamically added to the class. A typical implementation of a parameter writer method might look like:

private int _$read_parameter_value()
{
  if (_$value_cached || ! _$resources.isLoaded() || ! _$resources.isBound("value")) return _value;
  int result = ($r) ((java.lang.Integer) _$resources.readParameter("value", $type));
  if (_$value_invariant || _$resources.isRendering())
  {
    _value = result;
    _$value_cached = true;
  }
  return result;
}

The point of these examples is this: we’re doing some complex code creation and transformation and Javassist makes it easy to build up that logic by assembling Java-like scripting code. I’m not sure what the equivalents code transformations would look like in, say, ASM but I can’t see it being as straightforward and easy to debug. Javassist lets me focus on Tapestry and not on bytecode and that makes it invaluable.

Saturday, September 23, 2006

Type Coercion in Tapestry 5

I just finished a bit of work I'm very proud of ... a fairly comprehensive type coercion framework for Tapestry 5.

Here's the problem: with the way you bind parameters in Tapestry, you are often supplying a value in one format (say, a String) when the type of the parameter (defined by the variable to which the @Parameter annotation is attached) is of another type, say int.

So ... who'se reponsible for converting that String into an Integer? Tapestry. Get used to that answer, because that's a big theme in Tapestry 5.

At the core of the solution is a simple interface for performing type coercions:

public interface Coercion<S, T>
{
    T coerce(S input);
}

Gussied up inside all that generics goodness is the idea that an object gets passed in, and some operation takes place that returns an object of a different type. Perhaps the input is a String and the output is a Double.

Now, we dress that up with a wrapper that helps Tapestry determine what the Coercion converts from (source/input) and to (target/output):

public class CoercionTuple<S, T>
{
    public CoercionTuple(Class<S> sourceType, Class<T> targetType, Coercion<S, T> coercer)
    {
      . . .
    }

    public Coercion<S, T> getCoercion() . . .

    public Class<S> getSourceType() . . .

    public Class<T> getTargetType() . . .
}

My brief look at Haskell influenced the naming ("tuple") and a lot of the overall design.

Now we have a service, TypeCoercer, that can perform the conversions:

public interface TypeCoercer
{
    <S, T> T coerce(S input, Class<T> targetType);
}

The TypeCoercer is seeded with a number of common coercion tuples (thanks to Tapestry IoC, you can contribute in more if you need to). From these tuples, the service can locate the correct coercion.

Now the neat part is that if there isn't an exact match for a coercion, that's not a problem. The service will search the tuple space and build a new coercion by combining the existing ones.

For example, there's a builtin String to Double tuple, and a builtin Number to Long tuple. The TypeCoercer will see that there's no way to convert String (or any of its super classes or extended interfaces) directly to an Integer, so it will start searching among the tuples that do apply.

This all happens automatically. Say you pass in a StringBuffer instead of a String; TypeCoercer will construct the compound coercion Object to String, String to Long, Long to Integer.

Writing this code was very pleasurable; too often the things I work on are too simple: move datum A to slot B, and I get the whole design for such a piece of code all at once and its just a scramble to get it coded (and tested, and documented) before that mental image fades. This time I had to work hard (despite the very small amount of code involved) to really understand the problem space and the algorithm to make it all work ... then back it up with a good number of tests.

Thursday, September 21, 2006

Speaking at PJUG Sept. 26

I'll be doing a fast paced talk on Tapestry 4 at this month's Portland Java User's Group. This will be Tuesday, Sept. 26th at the Adtech II building in Northwest Portland. [map]

The meeting starts at 6:30pm.

Tuesday, September 19, 2006

Upgrading from Eclipse 3.1 to 3.2

I've been using an ever larger number of Eclipse plugins in my development. I'm using Jetty Launcher, Maven, AJDT (AspectJ), Oxygen (XML editor), Subclipse (SVN support), TestNG, and a few lesser ones.

Eclipse is pretty good about backwards compatibility, so I've tried just switching my eclipse folder from 3.1 to 3.2. Should be new JARs against my existing workspace and we're off and running.

No such luck. I was working on that yesterday and I quickly got to a point where I could not convince Eclipse 3.2 to even try and compile my code. It's on the class path, I can see the class files in the package explorer, but no dice on compiling.

My sneaking suspicion is that it's the Maven 0.0.9 plugin (this plugin keeps Eclipse dynamically up to date with your project's pom.xml).

So I downgraded to Eclipse 3.1. Guess what? No dice there either.

As you might imagine, this put me in a bit of a panic. I tried deleting my project and checking it back out of the repository. Still no dice. The panic level increased again.

My final solution was drastic: delete my workspace entirely. Eclipse stores considerable meta data about your project outside the folder itself. In the shuffling up to 3.2 and back to 3.1, some amount of that has been corrupted.

It's not so bad ... it's now spring cleaning time as I'm starting from an entirely fresh Eclipse install and even re-downloading just the essential plugins that I need.

Friday, September 15, 2006

Tapestry at The Ajax Experience

Jesse Kuhnert and I will be presenting at The Ajax Experience this year on Tapestry and Dojo.

Dojo is an open source JavaScript library that provides an improved programming model for JavaScript and a suite of client-side tools and widges. Tapestry is an innovative open source client-side Java framework for building componentized web applications. At first glance, these two look like the Odd Couple, but pull back the covers a bit and you'll see a similar event model and design philosophy that makes these frameworks a cinch to put together. Tapestry 4.1 with Dojo brings about client-side Ajax joy without server-side Java pain.

BeanForm Component

One of the compelling features in Rails is the ease with which forms for creating/editting/updating/deleteting objects can be created. Tapestry has a lot of power under the hood with respect to forms, but it still doesn't come cheap enough out of the box. A centerpiece of Trails is a component that builds a full form for editting an arbitrary object. This idea has resurfaced as a new standalone component, BeanForm.

Just plug the following into your page's HTML template:

<span jwcid="@bf:BeanForm" bean="ognl:pojo" save="listener:save" delete="listener:delete"/>

BeanForm will build a complete form from this, adapting to each individual property's type. If you are using EJB3 or Hibernate annotations, BeanForm will pick up those annotations to build out appropriate client- and server-side validations.

And its extremely extensible and customizable even beyond that. Cudos to Daniel Gredler for putting this together.