Just added the 700th test to the HiveMind test suite. I'm adding code so that you can omit the interface attribute on <service-point> when it matches the id of the service point. One interface, one service point (with the same name), one implementation class is a pretty common pattern.
Tapestry is closing in on 900 tests.
Whether we call it 3.1 or 4.0, the new version of Tapestry (supporting JSR-168 Portlets) is coming along. Basic forms and links are now working. The portlet namespace is used to extend the name generated by Tapestry (so instead of "Form0" you might see "Form0Pf0403f0dc0a8fe0201a826c5ae430341I"). That goes most of the way towards ensuring that JavaScript variables and method names are unique ... just a little extra tweaking will virtually ensure it.
The hardest part, besides cleaving Tapestry away from the Servlet API, has been the division between the action request and the render request. This causes a few problems ... not least of which is what to do with an error during the action request? We can't just render the response immediately ... I'm going to experiment with a solution where we render the response into a buffer that will be available in later requests.
Some similar problems exist for handling stale link and stale session exceptions. Nothing insurmountable.
The asset service is a bit of a pain; it will be necessary to map an ApplicationServlet, just to handle the asset service. The Portlet API doesn't include any concept similar to a servlet that renders a dynamic image. This is problematic for assets ... its even worse for getting Portlets to support Ajax-style operations. The worst part is that the servlet will need its own HiveMind Registry ... as will each Portlet.
Still, I'm pretty pleased with the progress and how its shaping up. Servlet Tapestry is improved as well. Of course, I'm brimming over for ideas for the next generation of Tapestry (5.0) where we get rid of abstract classes, inheritance (from Tapestry base classes) and XML specifications (in favor of annotations). But 3.1/4.0 (whatever we call it) will be quite extraordinary in its own right.
Jordan Redner, of shopping.com is a past client (I did a few days of training for them back in November). He's turned into a very enthusiastic Tapestry booster in the Bay Area. He recently wrote:
I work at Shopping.com and we've just rebuilt 3 major public-facing applications using Tapestry. The old versions were Perl/Mason.
With a core team of 3 strong Java developers, 1 CSS/HTML person, and 1 Oracle DB developer, we rebuilt what was estimated to take 4 man years in 4 months with some time to spare. I seriously don't think we would have been able to pull this off in Struts/JSP which was the runner up choice for us. In fact I think it could have been a disaster, taking much longer. The application is fairly complex and includes very rich I18N functionality such as rendering of strings in various language (from resource bundles & from the database), rendering currencies, collation by language, etc... Anyway, it was a huge application, and it has been a huge success. I am happy about it and needless to say, so is the business.
I've used many frameworks and have been doing web development for years in the Bay Area. Previously, I've managed and implemented large projects in ASP.NET with back-end Java components. I actually like the class-backing-a-page design of .NET which is similar to Tapestry, except for the fact that ASPX has the same pitfalls as JSP, and it's not Java.
One of the more frequent questions I get concerning Tapestry is ... how many sites are using it in the real world? It's a tough question, since I generally only hear from people who have problems and not nearly enough success stories. I asked around on the Tapestry mailing lists and got some pointers to a few sites ... here's just a few (that had cool logos).
TheServerSide.com should be pretty well known; it may be the largest Tapestry site, getting millions of hits per month.
TheServerSide.net runs on the same software, but with some different assets and configuration.
Shopping.com's main site just switched over from Perl/C++/CGI to Struts, but many of their current ancillary applications, such as Merchant account management, are done in Tapestry. They expect to use Tapestry on virtually all new internal and external web development.
The NHL may be having trouble, but it isn't because of Tapestry. Eric Everman, who created the site, tells me he is happy to return to more Tapestry work at NHL.com, after a painful sojourn into Struts development for another client.
Erik Hatcher and Jamie Orchard-Hays were part of the team that built a suite of applications for Darden ... in fact, that was one of my first Tapestry training engagements. The same application has been skinned and reconfigured for a number of clients, including the University of Chicago Business School.
This site was done by Paul Ferraro, a Tapestry committer who originated the friendly URLs patch for Tapestry 3.0. This site has also been repackaged and reskinned for a large list of clients.
And a few more I have no real information about (but I liked their logos):
And of course, there are far more than that. Geoff pointed out that Google can search for Tapestry sites due to the distinctive format of Tapestry URLs (if you aren't using the friendly URLs patch).
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:
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.
As a reminder, I'll be presenting a session on Tapestry to the Orlando JUG on April 12, 2005. Thanks again to Jay Zimmerman, of NoFluffJustStuff Symposiums for setting this up.
There are some people doing some pretty radical stuff with Tapestry of late. Kris Rasmussen recently showed off a number of screen shots of a very client-side intensive Tapestry CMS application.
All of the menus and behavior are done on the client side, using Tapestry. Basically, an outer ContentShell component wraps around some number of ContentSection components ... each of which is a container for content from a repository. If you are logged in as the administrator, the ContentShell displays the menus and allows you to upload images, edit content, etc. Exceptionally cool stuff! I hope he releases it as open source at some point.
Official news came down this morning; I will be presenting Tapestry at JavaOne 2005. I have a standard 60 minute time slot (45 minute presentation, 5-10 minutes of Q&A) and that's going to be a challenge. In addition, I'll be on the Web Frameworks Expert Panel, an hour-long, five-way discussion that will (tentatively) include Ed Burns for JSF, Craig McClanahan for Struts/Shale, Jason Carreira for WebWork, myself for Tapestry, and possibly one additional, unnamed person (Echo? Wicket?).
Just added a few more portlet tests to the Tapestry test suite ... there are now 800 tests in the suite (plus about 650 in the HiveMind test suite). That's a lot of tests! Since I adopted EasyMock as the core of my unit testing strategy, the number of tests in both products has exploded. However, I think I'm hitting a ratio of 3:1, maybe even 5:1, test code vs. production code. In this respect, my current development style, especially for something as ambitious as Tapestry 3.1, is a marathon and not a sprint.
More things for my to do list:
The refactoring has been continuing for Tapestry. I've been working for weeks, adding features and doing the refactoring needed to support the Servlet API and the Portlet API simulateneously.
Over five years ago (yowza!) when I was first working on Tapestry, there was a point early on where I had to code for well over a week just to get to "Hello World". In retrospect, that was a sprint and this is a marathon ... also, I don't code the same way anymore (writing tests as you go is a slower process that gets your to your destination faster).
Regardless, in the next couple of days, I should get to "Hello World", Portlet style. Of course, that's just part of my to do list:
The worst is, I'm sure I'm forgetting a bunch of things!
When I told people my tale of woe concerning my laptop, I got a fairly universally negative response about Dell. All I can say is that, short of dumping a tall glass of water into my keyboard, I've had zero problems with my Inspiron 8200 for nearly three years.
In fact, Dell under-promised and over-delivered. The five to seven business days turned into ... two. They picked it up Monday afternoon, and I got it back Wednesday afternoon with a new keyboard and new (or refurbished) system board. Everything seems to be working fine. I was steeling myself for a full re-install of Windows and all my tools (which is not a bad idea, to be sure!) and instead I'm back up and running as if it never happened.
So I'm back to puzzling out the eXo portlet container. Looks like it will be easier, once I get the hang of it, to test my Portlet Tapestry using eXo than Jetspeed ... it's just a much richer, more polished tool. Ultimately, I'll verify against a number of different containers.
Just received my invite to present at the O'Reilly Open Source Convention, August 1 - 5, 2005 in Portland, OR. Erik Hatcher has spoken very highly of this conference ... but trying to say anything about Tapestry in 45 minutes is going to be very tough.
Meanwhile, I'm waiting to hear back about my JavaOne session (on Tapestry). I've gotten some hints and assurances from the inside that this will happen.
I've gotten a bit spoiled by TheServerSide Symposium and No Fluff Just Stuff who pay your expenses. For Portland, I can live with it (it's a fun city to visit) ... and for JavaOne, that's just too good on the resume to miss!
I can't even start to detail everything that's happened in the last few days. Basically, I started my trip by dumping a glass of water into my trusty laptop, which fried the motherboard. Fortunately, I had bought a backup laptop (primarily used by my wife Suzanne) and was able to borrow this for the trip ... the contents of my internal hard drive was eventually recovered by Tech Fusion. I was literally sitting down at my laptop to run my traditional pre-trip backups when this happened and my nearest backups were a couple of weeks out of date.
Viva open source -- most of my development environment was downloadable from the Internet, and my key files (the Presentation Examples) are online.
The actual sessions went quite well; my Tapestry session was a bit different from the rest of the conference, more hands on, as I develop the trusty old Login page. The audience was really into it, asking lots of great questions. JSF Spec Lead Ed Burns was in the front row.
The second session went a little short and we made up for it with more detailed Tapestry and HiveMind questions.
I also worked with Chris Nelson, the creator of Trails. I think Trails will be a very important technology for Tapestry for both practical and marketing reasons. Trails has some unusual use cases that we will extend the APIs to handle more cleanly (for example, Trails needs to "sniff" for pages, based on naming conventions, that may or may not exist).
I spent a good amount of time talking to Ed Burns; he was showing me the internals of the JSF RI and we were comparing notes. I also talked to Rob, Colin and others from the Spring team, particularily about Spring Web Flow. Just from ten minutes of conversation, I believe we spotted a couple of changes to Spring Web Flow that would make it easier to integrate with Tapestry. Ten minutes of face time can be worth a month of emails.
In fact, for me, that was the point of the conference: networking (and a little sales). I lost track of the number of people I talked to about Tapestry and Tapestry training. Now, the TSS attendees are not a representative sample of the J2EE market I think, but what I heard was how many people want to use Tapestry, or at least learn about it. Something about Tapestry does picque many people's interest, and inspire a kind of passion in those that already use it. But the JSF juggernaught is still looming in the background, and I'm continuing to look for ways to better differentiate Tapestry from JSF.
Dion and Ben's Ajax presentation was eye opening for me. Yes, it's technology that's been around for a while ... it's just that a bunch of small things have aligned to make it more practical to do significant client-side work. Tapestry is already well positioned to create "Ajaxian" components and applications because it has two key pieces: 1) sophisticated, dynamic JavaScript generations. 2) an abtraction (engine services) that will support rich communication between the client side and the server side ... without requiring any configuration inside web.xml.
Additionally, I found some time (really, stress relief) to work on code. Big accomplishment was improved line precise exception reporting, where the location is supplemented by the actual source listing (with the offending line highlighted). This is a good idea, but I created (of course) a wildly flexible implementation where adapters for objects can be registerred that are used to output or describe objects. I can see this being helpful when dealing with existing objects that don't implement a decent toString().
I'm busy using this technology to output the Servlet API and other stuff on the Exception page and working towards eliminating the RequestContext object ... everything you'd do with it in Tapestry 3.0 is either methods directly on the IRequestCycle, or has been moved to other services, or is an object (such as the WebRequest or HttpServletRequest) that can be injected into pages, components or services.
Meanwhile, I get to work in a somewhat crippled manner for the next week or so while my laptop is at Dell getting replaced or refurbished. I miss my big, high-resolution screen and my normal keyboard (the feel of the Inspiron 1000 keyboard is "cheap" by comparison with the 8200) and lots of other little things. I also miss about half a gig of RAM and a faster CPU. I'm kind of hoping that Dell replaces my computer with a newer Inspiron (with USB 2.0). But I can squeek by for a little longer like this.
My TSS Tech Talk Video, taped at last year's TheServerSide Symposium, has finally gone live.
