I've been working on some new features for Tapestry 5.1. Importantly, I've been trying to get my head around Spring Web Flow and how that would integrate with Tapestry without sacrificing the flavor of either framework ... fortunately, Keith Donald (SWF Head Honcho) has been helping out.
I'm also very interested in performance ... or really, throughput. I made a number of changes in December that dramatically improved Tapestry performance for very large and complex pages (with thousands of component renders). It can be an uphill battle, given that Tapestry creates an in-memory DOM of the page and streams that out at the very end (unlike a JSP that can spit out bits and pieces of content immediately at the start of its render). There's certain overhead in creating all those DOM objects and then navigating them while rendering. So where we take away on one side, we need to add back on another ...
The goal is to minimize the amount of traffic over the wire; specifically, the amount of static content: assets such as images and stylesheets that don't change during the life of the application.
Tapestry 5.1 now has built-in GZIP compression of responses, both for dynamic page renders (traditional and Ajax) and for those static assets.
I'm also automatically building versioned URLs for context assets (not just classpath assets stored inside JARs); they'll get the benefit of automatic compression and far-future expires headers too.
This falls into my vision for Tapestry in particular, and frameworks in general: they should help you employ best practices, even if you don't even know such practices exist. Just using Tapestry becomes a best practice all by itself*.
Another way to embrace this view is to see Tapestry as the embodiment of the combined experiences of the Tapestry developers and community over the last many years. Good lessions, hard won, realized in code.
*At this point, steam should be coming out Ted's ears!
8 comments:
Well Howard, the current trunk contains very interesting features and by my point of view far more interesting then spring web flow support.
The new IOC features are amazing for us as libraries builders!
It's really going to kick ass!
Thanks; I'm very happy where the IoC stuff is going and I'll probably slip some more in.
One thing I didn't make clear here is that all the changes I'm making are 100% backwards compatible. You upgrade, you get the new features (though some of them work better when tuned).
One quick question: any ETA on Tapestry 5.1?
I'm hoping to roll out a new Tapestry every 4 - 6 months; if that actually works out, then April?
I think the emphasis should stay on easy and frequent upgrades.
Don't want to lower enthusiasm here, but although T5 is already really cool web framework, it seems to me that it still needs to polish some tiny core things like Submit button having context, or some things like that...
I always considered features like Hibernate support, SpringWebFlow integration etc... to be just nice additions that can sometimes be just burden if these libraries don't be popular anymore, where core features like basic HTML, JavaScript (or even Ajax) are always priority.
I especially never got impression that Spring Web Flow is much used around. It's maybe just good political move since Spring is such a giant in OS world nowadays.
Or maybe just Tapestry users are so different in what they think is most important... :-)
As a T3/T4 user, I am happy to read the vision of encapsulating best practices. Two practices that come to mind as particularly important are:
1. redirect-to-get-after-post - ensure that after a HTTP POST, the POST response will redirect the browser to a bookmarkable URL that is accessible via HTTP GET.
2. prevent-duplicate-post - ensure that a user, who has clicked on a button to post a form, cannot post the form again thereby duplicating the request. This is probably done with a combination of JavaScript to disable the button after clicking, and some kind of hidden field (unique id or version number) for the form instance.
If T5.1 can remove this tedium from the app developer's burden, that will be a tremendous relief!
Ben: we're half way there; Tapestry fully embraces redirect-after-post (or any other state changing action).
Duplicate form submission detection is trickier, especially when trying to do so in a cluster.
Hi... Is it possible to write Tapestry with just Groovy? I think it would be very cool.
Post a Comment