I'm very proud to announce that the next major release of Tapestry, release 5.2, is now available as Tapestry version 5.2.4.
This is the first stable release of Tapestry since 5.1.0.5 (back in April 2009), which is far too long a cycle. You might wonder: what's been the holdup? The answer, for myself personally, is that I've been using Tapestry on two very, very different applications for two very, very different clients and I've been updating Tapestry to embrace the real world concerns of both of them. At the same time, I've done about a dozen public and private Tapestry training sessions and gathered reams of input from my students.
Let's talk about some of the major enhancements in this release:
Removal of Page Pooling
Prior versions of Tapestry used a page pool; for each page, Tapestry would track multiple instances of the page, binding one page instance to a particular request. This was an important part of Tapestry's appeal ... all the issues related to multi-threading were taken over by the framework, and you could code your pages and components as simple POJOs, without worrying about the threading issues caused by running inside a servlet container.
Unfortunately pages are big: it's not just one object but instead the root of a large tree of objects: components and templates, bindings for component parameters, component resources, and all the extra infrastructure (lists and maps and such) to tie it together. Some of the largest Tapestry projects have hit memory problems when they combined deeply componentized pages with large numbers of parallel threads.
Tapestry 5.2 rewrites the rules here; only a single page tree is now needed for each page; the page and component classes have an extra transformation step that moves per-request data out of the objects themselves and into a per-thread Map object. Now, any number of requests can operate at the same time, without requiring additional page instances. Even better, the old page pooling mechanism included some locking and blocking that also gets jettisoned in the new approach. It's just a big win all around.
Live Service Reloading
People love the ability to change page and component classes in a Tapestry application and see the changes immediately; prior to 5.2 the same people would be disappointed that they couldn't change their services and see changes just as immediately. Tapestry 5.2 eliminates that restriction in most cases.
This is super handy for services such as DAOs (data access objects) where it is now possible to tweak a Hibernate query and see the results as immediately as changing some content in a template. This is another Tapestry feature that you'll find you can't live without once you use it the first time!
ClassTransformation API Improvements
At the heart of Tapestry is the Class Transformation API; the extensible pipeline that is the basis for how Tapestry transforms simple POJOs into working components. Prior to 5.2, if you wanted to do any interesting transformations, you had to master the Javassist psuedo-Java language.
Tapestry 5.2 reworks the API; it is now possible to do all kinds of interesting transformations in strict Java code; Javassist has been walled off, with an eventual goal to eliminate it entirely.
Query Parameter Support
Tapestry traditionally has stored information in the HTTP request path. For example, a URL might be /viewaccount/12345
; the viewaccount
part of the URL is the name of a page, and the 12345
part is the ID of an Account object. Tapestry calls the latter part the page activation context (which can contain one or more values).
That works well when the a page has a fixed set of values for the page activation context, but not so well when the values may vary. For instance, you may be doing a search and want to store optional query parameters to identify the query term or the page number.
Tapestry 5.2 adds the @ActivationRequestParameter annotation that automates the process of gathering such data, encoding into URLs as query parameters, and making it available in subsequent requests.
Testing
A lot of work has gone into Tapestry's testing support, especially the base classes that support integration testing using Selenium. The new base classes make it easy to write test cases that work independently, or as part of a larger test, automatically starting and stopping Selenium and Jetty as appropriate. Further, Tapestry expands on Selenium's failure behavior, so that failures result in a capture of the page contents as both HTML and a PNG image file. It is simply much faster and much easier to write real, useful tests for Tapestry.
JSR-303 Support
Tapestry now supports the Bean Validation JSR, converting the standard validation annotations into client-side and server-side validations.
Documentation
Tapestry's documentation has always been a challenge; for Tapestry 5.2 we've been doing a massive rework; doing a better job of getting you started using Tapestry; it's still a work in progress, but since it's based on a live Confluence wiki (and no longer tied to the release process) the documentation is free to quickly evolve.
Better yet, you don't have to be a committer to write documentation ... just sign your Apache Contributor License Agreement.
And in terms of exhaustive guides ... Igor Drobiazko's book is being translated from German to English as Tapestry 5 In Action.
Summary
I'm very proud of what we've accomplished over the last 18 months; we've added new committers, new documentation, and lots of new features. We even have a fancy new logo, and a new motto: Code Less, Deliver More.
Tapestry 5 was designed so that it would be possible to make big improvements to the internals and add new features to the framework without impacting existing users and applications; Tapestry 5.2 has validated that design and philosophy. It delivers a lot of punch in a non-disruptive way.
So, if you are looking for a high-productivity, high-performance web framework that doesn't get in your way, it's a great time to take a closer look at Tapestry!
Is it possible to gather all (existing) Tapestry documentation pages (if they make sense as related) into a big single PDF (with, if possible, a smooth learning curve) ?
ReplyDeleteThanks.
Well, I like web pages, but when learning a new technology, hypertexts could bring trouble while trying to follow a logical learning line. Let's give you another example: when I read a big PDF doc, if some info is missing, producing a "gap" into the learning curve, then I know there was a pb during writing, and I am then able to submit on a ML my opinion about it. On the other way, when I read web pages, if something is missing, I first wonder I have missed some info/hypertext into the web site, and I start digging into the web site, looking for it: first, I may loose time, and secondly, I may get frustated because I may not be able to know if I missed something myself, or if the info is really missing into the web site.
Well, the other point is that I find too more convenient to download once a big PDF, and reading it printed, for example, during transportation, than printing different web pages and putting them together...
This will be available fairly soon as "Tapestry 5 in Action".
ReplyDeleteNote that I was talking about something like putting web site's docs into a global PDF, not looking for "outside" doc ;-)
ReplyDeleteThis being said, I am not against buying computer science books, I have already bought few of them this year...
While "Tapestry 5 in action" is going to be released, is Alexander Kolesnikov's "Tapestry 5" going to be outdated ?
Thanks
Would you add @PageReset User Guide > Page Life Cycle ?
ReplyDeleteSome colleagues had hard times finding this annotation.
that all sounds very well, especial the documentation! In the past it was some time very expensive to find how some thinks can be implement :)
ReplyDeleteI am currently finishing to read the Alexander Kolesnikov's book "Tapestry 5". I have yet to read the final chapter 8 (about creating custom components) to finish it.
ReplyDeleteIt leads me to caracterize Tapestry according the following idea:
(1) DDD: Tapestry does not separate Form and Action into different classes like Struts
(2) page-centric
(3) convention over configuration: for binding purposes
(4) code what you need: one needs to code, for example, an onActive() method in a POJO if and only if one needs to catch the 'activate' event.
Well, Tapestry looks like definitely more high-level than Struts.
Point (4) is about Tapestry easy-to-use testimonial, and puts me to think Tapestry much more as a DSL than a framework (good point).
But I have been disappointed to learn an event handler could not return an instance of a POJO to go to the next page. As a consequence (!), it looks like unfortunately that data are transmitted between different POJOs through a persistence mechanism on top of the http session (as far as I have read correctly the book).
(a) after having reading this book, I just remember the http session looks like the main way to pass data between POJO: it looks like there is no use of the lightweight setAttribute() method on HttpServletRequest object. So, it looks like Tapestry has much more impact on the http session, and challenge more the use of this session, than, let's say, Struts.
And, while the above book has been the single (?) english book for Tapestry during a long time, and while you have been a reviewer, I just want to point some facts that have impacts about Tapestry's evaluation:
(b) there is a single (!) mention of generated JavaScript (for the client-side), page 168
It appears somewhat some (?) controls are generated in JavaScript, no more.
While JavaScript generation has impact on client/server roundtrips and then, on the number of requests sent to servers, it's unfortunate such a book does not dig into this subject.
(c) all examples are about (up to chapter 7, I don't know about the final chapter 8) total page refreshs.
There is no example of partial page refresh.
(d) I would have appreciate a master/detail example, with details displayed into a layer.
Indeed, while Tapestry appears as page-centric, I expected to see an example involving layers to see how well it fits (while I have little doubts Tapestry could handle layers).
Why have I written few points above ?
In fact, I just want to tell you I see Tapestry as a more high-level web framework than Struts, and then, I see it helps to be more productive.
However, as I build web sites targeting a high-level workload, I still have to give answers to the points above (to have a more detailled opinion on Tapestry, and to be able to tell my managers I could rely on it) ; the points are less high-level, but still important for high-performance point of view (Devil is into details), and I have the feeling that, while Struts is too low-level and Tapestry much more high-level, there is a gap between them, and I have not a clear view on how Tapestry fill this gap.
So, I see unfortunate the main book available these last years (250 page) does not give these infos, while this book is quite *very* well-written on the other subjects!
And then, while I think Tapestry could give an (for me, yet-to-know) appropriate answer to these points, I still think more documentation would be appropriate to let me more appreciate your baby and to let it walk much more better for other people's projects. It desserves more complete books (docs?). I hope "Tapestry 5 in Action" would be help here.
My 2 cents.
With regards.