These are my impressions after using Tapestry for a couple of weeks. I review the flaws and joys that I found in using Tapestry.
When doing web development in Java, there is an abundance of frameworks and it's often a point of criticism.
To me, this variety is valuable. Some new frameworks are formed out of disagreements or the desire to "do it yourself", true, but many are created because of limitations of existing systems and because of ideas that are different enough to warrant it. Without this, there wouldn't be competition, and we would not be seeing as many features as we do now. We would just have a billion different Struts.
Having so many frameworks is intimidating. You may be forced to wonder, "Is the framework I'm using the best for what I need or is maybe one of those other frameworks better?" A question like that is difficult to answer because time is limited. When I get a chance, I try to explore new frameworks and sometimes even revisit ones that I dismissed before. This time I decided to try Tapestry 4.
Going in, there are already things that make Tapestry less desirable compared to other frameworks. Tapestry 5 is on it's way and it's not backward compatible with Tapestry 4. Tapestry has a history of redesigns so as far as anyone knows, Tapestry 6 might one day be released and not be compatible with Tapestry 5. Not very encouraging for use in any kind of project. From the academic point, it may not be so bad; Limitations can be fixed and new ideas can be implemented without being limited by the old design. Having said that, I don't think Tapestry will truly gain popularity until they come up with a great design and focus on it instead of on how to change it.
If there's a problem, Tapestry will do its best to pinpoint it and give you a good description. Most of the time, Tapestry will not silently ignore a mistake such as mistyping a component name. You'll know if you made a mistake. I did run into a problem that Tapestry didn't tell me about, but I wouldn't necessarily blame Tapestry. I renamed a Page class but did not rename the associated Page template. When I went to the page, Tapestry happily loaded the template, but obviously did not find the class. I spent a while wondering what was going on. An option to make classes required by default would have been nice. I would have been satisfied had I gotten a "class SomePage not found" error. Tapestry is a component framework after all, so it's only natural that components work well. Components are easy to define, flexible, reusable and are easy to package. Page flow is easy to handle. Taking the user through different screens is not a hard task.
Most of your page classes will extend BasePage. Your class will be abstract and will be dynamically subclassed when the page object is instantiated. For retrieving submitted data, it's a nice approach. You define an abstract method which is implemented by Tapestry during runtime. This lends itself to easy refactoring as compared to using literal property names. For other things, it's not so great. For one, making your class abstract allows for some runtime errors. If you implement a listener, but don't implements all the methods, you won't get any help from the compiler. As far as it's concerned, it's an abstract class. This also means you can't use Quick Fix in Eclipse to "Add unimplemented methods," to which I'm used to. From what I read, things are no longer done this way in Tapestry 5, but I haven't actually read on which approach it takes. Those tables smell fishy ... There's a Table component in the contrib library. If you want a column rendered in a custom way, you have to define a component outside the table component and give it an id composed of the column name and the "ColumnValue" prefix. From the get go, this seems like a big hack. Why is it defined outside the table component and why does it rely on a certain component name? One typing mistake and your custom rendering will be disabled without any errors on the page. This give me the impression that there are problems with the component architecture. Ugly URLs are a problem with component frameworks. Tapestry has means to beautify URLs, but I haven't tried them yet, so maybe it doesn't have to be a bad thing. On the Tapestry page, there are a number of links to Eclipse plugins for working with Tapestry templates. I checked them out and I didn't find any tools that are in any way usable. I found one active project, but it's a plugin for IntelliJ, not Eclipse. I am planning to try that plugin out in the near future. There are people that decry any kind of tools, but I'm not afraid to use anything that will make me more productive. Productivity speaks. If I'm making a Tapestry template and I'm defining a component, why not have the ability to have a tool fill in the page spec for you. It's just tedious work that is prone to errors and can be handled by a tool. A plugin could also validate your templates as you write them. Tapestry 4 traffic on the mailing list seems to be quite low. I posted a question about a problem I have with auto-wiring not working in my project and did not see any suggestions. I know that it's a bit silly to be trying Tapestry 4 at this point in the game, but it serves to satisfy my intellectual curiosity. I don't claim to be an expert these topics, so I would not be surprised if there are problems with what I wrote. There are more things under "dislikes," but that's only because negatives are a lot easier to see. I found Tapestry 4 to be overall a satisfying experience. I want to go back and try Seam again. I had tried it around version 1.0 and 1.2 BETA and found a lot of annoyances. I have heard about some positive experiences with it and that has me interested.