Tapestry Portlet Hello World

Well, it's only been a few weeks of hacking, but I do have Tapestry Portlet Hello World running side eXo:

For the moment, I'm calling these "Taplets" (Tapestry Portlets). There's still a lot of work to be done, but this is very encouraging.

Meanwhile, the changes in 3.1 continue to mount and the other committers (including Erik Hatcher, who has been a Tapestry 3.1 alpha guinea pig) have started to chant 4.0! 4.0!. That's one option, another is to restore a few missing things, like RequestContext as access point to the HttpServletRequest. Also, the fact that the AbtractComponent base class makes the getMessages() and getComponentId() methods abstract is giving Eric more headaches.

Of course, if it becomes Tapestry 4.0, I would start really fixing things, starting with abstract classes and required inheritance. Here's a thumbnail of what Tapestry 4.0 would do:

• The page/component hierarchy still exists, but there's exactly one implementation of IComponent.
• Each component has a peer; this is the class you provide.
• The peer has the component injected into it.
• The peer does not extend any class, though it can implement the various listener interfaces (such as PageValidateListener).
• The peer may implement IRender, in which case the component will delegate rendering to the peer (otherwise, the component will render using a template).
• The page/component specification is optional.
• Page/component names must map directly to Java classes (by searching for classes within a list of packages). These classes are for the peer.
• The .page file must be in the same folder as the .class file.
• Each page or component must have a unique peer class.
• The class loader will be extended to modify the peer class as it loads:
  • Instance variables are self-encapsulated (i.e., _myProperty --> getMyProperty()).
  • Accessor methods are rewritten for transient, persistent, or parameter properties
  • Other enhancements as with 3.1 today (i.e., to inject assets, components, ASOs, etc.).

It's pretty daunting, especially considering my current schedule, and it needs to be fleshed out some. The end result will be more distant from Tapestry 3.0 than 3.0 is from 2.3. It will be a chance to clean house: to clearly separate APIs (such as IComponent) from SPIs (such as TemplateParser or ComponentSpecificationSource). In fact, I would love to have a internal package where backwards compatibility from release to release is a non-issue. It's also a chance to get rid of the leading 'I' on interfaces!

Scary stuff; times like this I really feel the weight of the world on my shoulders.