I'm beginning to wind down on changes I want to make for Tapestry 5.2. As you may know, I've been balancing my time between two different clients, as well as development of Tapestry itself, and of course, my three month old son (another prime consumer of my time).
In any case, I've made quite a few changes to Tapestry to support the needs of my clients, and also to start two important transitions: The first transition is to move away from Javassist to a simpler, more stable (more JDK 1.6 compatible) approach to dynamic class generation and runtime bytecode transformation. This has been reflected in the new ClassTransformation APIs. However, there is more yet to do, including a similar update of the ClassFactory/ClassFab APIs. Will that last part make it into 5.2? The second transition is the gradual re-writing of the tapestry.js client-side layer. As I've grown more proficient in client-side JavaScript, I've been moving away from my early approach, which was essentially Java-in-JavaScript, by way of leveraging the Protoype class functionality. Where I'm at now is a more functional (if still stateful) approach based almost entirely on event publishers and observers combined with JavaScript closure functions. I feel a gradual move in that direction is the way towards eventually replacing Prototype & Scriptaculous with jQuery, and making it possible to cleanly support other JavaScript foundations. I've been hoping to introduce two additional layers on top of Tapestry: support for Spring Web Flow and for Portlet development. Both of these keep getting deferred out due to lack of time on my part. In addition, I feel that the current Tapestry URL rewriting layer needs to be revisited, even in a non-backwards compatible way. The current approach has a number of gaps in functionality, and a somewhat awkward approach. I think we could create something simpler and more effective (and capable of handling asset URLs as well as component event and page render request URLs). I know there's a backlog of bugs to be dealt with; some are hard, many are not. Some are drudgery. It would be nice to see at least the low-hanging fruit addressed. Simply cleaning up duplicate issues in the backlog would be a great benefit! I'd be interested to hear what the other developers see as must-haves for a 5.2. I know I'd like to see what's going on with the new Confluence documentation. I think, once we draw a line in the sand, we can have a final 5.2 release out very quickly (the code is stable and well tested). In fact, finalizing before JavaOne in September would be ideal. I am, however, concerned about memory and performance issues brought on by the new ClassTransformation APIs. We may need to find some time to profile & optimize that part of Tapestry. Finally, after 5.1 I deliberately took a step back from coding Tapestry; my original intention was to not let myself be distracted from writing a book. The book didn't happen, I've been fortunately quite busy with Tapestry project work, but I was immensely pleased at the way the other committers filled the gap in terms of new features, the new CI server and Nexus, and backporting of important fixes to stable releases, and now the documentation upgrade on the Confluence server. Truly awesome! But for 5.3, I expect to start writing new code as soon as 5.2 hits the release servers, if not sooner! -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
