The inside scoop on what's happening with Tapestry ... from the creator of the Apache Tapestry framework. Plus all the normal, random thoughts on coding and technology.
Last week was a bit of a blur, a mix of severe jet lag, a bit of over-indulgence at the speaker's dinner, and the thrill of presenting on Tapestry and on Clojure in a rock-star environment. Devoxx is well known for the venue ... speaking in front of a three story screen to a crowd numbering in the hundreds is a bit different that chatting to a group in front of a whiteboard, I can say.
If you were at the show, please take a minute to rate my sessions:
I've been consciously letting Tapestry 5.1 sit and stabilize for a while ... a time that's stretched a few months longer than I initially intended.
This is due to a number of factors: my return to independent consulting, my desire to write a definitive Tapestry 5 book, and preparations for many trips and speaking engagements.
All of these factors have worked on each other: I've been improving and extending my Tapestry Workshop training materials which can be quite time consuming. I've also (over the last several months) been on the road several times, talking about Tapestry or doing Tapestry training.
I do want to write a book on Tapestry but if I start writing 5.2 code, I know I'll be sucked right in ... lots of code (that darn Spring Web Flow integration for sure this time) and bug fixes.
In addition, I've had an embarassment of riches: two main clients, one regular part time, and the other requesting (but not always getting) all my remaining time. I also have additional clients and training engagements waiting in the wings. I simply have a lot of draws on my time.
As usual, working on real-world projects lets me experience the "rough edges" of Tapestry and fills me with ideas on how to address those in the next release ... often by splitting up Tapestry services into smaller, more easily overridden chunks and carefully moving internal services out into the public APIs.
Finally, I've been very pleased by the fact that as I've stepped back temporarily from my normal stream of commits, the other Tapestry developers have stepped in and filled the gap. There's been quite a bit of activity especially from Igor that I've barely had a chance to keep up on.
So the question is: do I wait and see if time opens up in Q1 to actually start on a T5 book ... or do I jump into 5.2 coding and leave books to others? It's much, much easier to write code than to write a book ... a book is a large amount of concentrated effort. It's very hard to accomplish anything on a book using an hour here or an evening there ... whereas Tapestry's code base lends itself to that kind of effort quite nicely.
Meanwhile, in spare minutes (and during sessions at ApacheCon), I've been continuing to work on Cascade. It's been a great learning exercise for me, pushing my understanding of both Clojure and functional programming in general ... and especially, some pretty advanced meta-programming with macros.
I'm also using Cascade as a kind of test bed for ideas that will eventually appear in Tapestry.
Not everything turns out exactly as I've planned. For example, I've been very excited about invariants, portions of the rendered DOM that could be cached from one request to another, to speed up the rendering. Like Tapestry, Cascade views render a DOM structure which can be manipulated (in an intermediate stage) before being streamed as text. This is a useful and powerful concept in a number of ways.
My thinking has been that a typical view will contain sections of the template that are invariant: unchanging, and that there would be a benefit to building that sub-section of the DOM once and reusing it efficiently in later renderings of the view.
Clojure template forms are processed by macros to become normal Clojure code. Thus something like (template :p [ "Hello" ]) will be transformed into code, approximately (element-node :p nil (combine (text-node "Hello"))). My approach was to tag the new Clojure code forms (the list consisting of element-node, :p, etc.) with meta data to identify it as invariant. Eventually this would propagate up to a higher level and code to manage a cache would be wrapped around it: (or (read-view-cache 97) (update-view-cache 97 (element-node :p ...
Fun stuff ... until I put it into practice (after a fair amount of debugging) and discovered that in the views I've created so far (for testing purposes), the number of nodes that can be cached is low; any use of a symbol or a function call mixed into the template "taints" it as variant. I wasn't set up to do performance measurements, but my gut feeling is that the overhead of managing the caches would overshadow the savings from the small islands of reused DOM nodes.
Back to Cascade as a learning experience: just because this didn't work out doesn't mean I didn't learn a lot from heading down that direction, and certainly the amount of code it took was quite small. I have it stored in a branch in case I ever want to give it another shot.
I will have all the basic features of Cascade implemented pretty soon; I'm looking forward to seeing what the larger Clojure community makes of it. In the meantime, it has served as a great way for me to dig deep into Clojure ... I'll be putting together more sessions for NoFluffJustStuff and more articles for the companion magazine based on all this.
I've been doing a lot of work for a client using the ExtJS library and that, combined with many other things I've been looking at, has started to shift my attitude to the correct approach to client-side JavaScript. Not a sea change, just a minor adjustment.
Until now, I've had the approach that the page should popup "complete" and that the JavaScript should only manipulate (or add to) the content already present. In most cases, such as adding validations to user input fields, that works fine: you write out the HTML for the field, remember the id for the field, then add JavaScript that adds event handlers to the field, finding it by its id.
However, for more complex cases, such as Tapestry's Palette component, I've been coding like its 2001 for too long.
The Palette component renders out two <select> elements, plus a number of <divs>, a few buttons, and a chunk of JavaScript to connect it all together. This means generating a lot of related ids on the server (to match against the generated HTML markup) and passing those down to the client.
It's effective but it reflects my relative naivete with JavaScript back in 2001. It's now so much easier to create a DOM structure on the client, using any of the major JavaScript libraries. That, in turn, makes it much more reasonable to just write out an empty <div> element with an id and install into that empty space all the markup for the component, generated on the client side. In fact, I envision a version of the Palette for Tapestry 5.2 that starts as a <select> configured for multiple selection and is converted on the fly to the familiar Palette component entirely on the client side ... which means that it could actually operate in a functional, if limited way, even if JavaScript is disabled in the client.
ExtJS includes a number of other ideas that are worth thinking about; I've been very impressed by the concept of a separate controller hierarchy on the client side (ExtJS calls these "components" as differentiated from the DOM nodes they create and manage). That's something that's ad-hoc and inconsistent in Tapestry's client-side library. I think embracing a similar, more structured approach could make it easier for Tapestry to embrace even more dynamic Ajax behavior.