Wednesday, April 13, 2005

Improved Listener Methods in Picasso

I'm always on the look out for ways to further simplify Tapestry development; that's one of my core principles. Simplicity. I personally love complexity ... on the inside, doing the magic that makes the end-developer's job that much easier.

One thing that's bugged people for a while concerns listener methods. These are public methods on your classes that can be invoked by forms or by the DirectLink component.

A common thing to do with DirectLink is to pass additional information in the URL. This information takes the form of listener parameters (which were confusingly called "service parameters" in 3.0 and earlier). Anyway, you can ask the request cycle for the parameters, and then extract and cast them to the right types. But that's not simple enough.

For example, suppose that the link encoded a String objectId and an integer index. The component in the template names the listener method, and the two parameters are passed into the DirectLink as an OGNL list expression:

<a jwcid="@DirectLink" listener="doClick" parameters="{ objectId, index }"> . . . </a>
This shows another recent recent improvement: the "listener:" prefix is assumed for the listener parameter, and "ognl:" is assumed for the parameters parameter. If that's not appropriate, you can still provide an explicit prefix. Kudos to Erik Hatcher for that idea.

In the Java class, the listener method might look like:

public void doClick(String objectId, int index)
{
  . . .
}

That's the innovation and simplification; the listener parameters are automatically converted into method parameters, saving you the trouble you'd have to do in release 3.0:

public void doClick(IRequestCycle cycle)
{
  Object[] parameters = cycle.getListenerParameters();
  String objectId = (String)parameters[0];
  int index = ((Integer)parameters[0]).intValue());
 
  . . .
}

The change is backwards compatible; there's a little search for the best matching method implementation, and the last thing checked is the Tapestry 3.0 style listener method (with the single IRequestCycle parameter).

I honestly can't remember where the idea for this came from; it seems so obvious in retrospect that you'd think I came up with up, but I think it was Erik Hatcher again. Oh, and the test suite is up to 960 tests, 277 seconds, and 82.4% code coverage.

3 comments:

  1. This is a very nice improvement - well done!

    ReplyDelete
  2. I am assuming that you can still get to the request cycle through the getRequestCycle() or getPage().getRequestCycle() facilities that exist within pages and components?

    If so this is a massive improvement in functionality - congrats to erik and yourself for both suggestion and implementation.

    ReplyDelete
  3. This change is fully backwards compatible to 3.0.

    To invoke listener methods on non-components ... look at the implemention of getListeners() on AbstractComponent and on AbstractEngine. The implementation is basically ListenerMapSource.getListenerMapForObject(this).

    If you have model objects, they'll need to to implement something similar.

    For Trails, a possiblity would be a new binding prefix, say "model-listener:". The binding itself could take care of obtaining the listener map and delegating to it.

    ReplyDelete

Please note that this is not a support forum for Tapestry. Requests for help will be deleted. Please subscribe to the Tapestry user mailing list if you are in need of support, or contact me directly for professional (for pay) support.

Spammers: Don't bother. I delete your comments and it's a waste of time for both of us. 垃圾邮件发送者:不要打扰。我删除您的评论和它的时间对我们双方的浪费