Thanks! That was a key, early priority in Tapestry.
Way back at servlet API 2.1 and JDK 1.2, Tapestry would still do a great job reporting exceptions (and still does).
Tapestry uses a lot of nested exceptions, the exception reporter uses reflection to dynamically "dig out" nested exceptions, showing a stack of nested exceptions. Each exception is identified, along with message and any JavaBeans properties. The stack trace at the deepest level is displayed. In addition, full output of the various Servlet API objects is dumped out.
I've had colleagues say that, everything else being equal, they would use Tapestry just for the exception reporting.
The goal is to send the developer right the offending line without having to reproduce the problem using a debugger. Big time saver.
Moral of the story: Tapestry is not demo ware, it is serious code developed by a serious coder for other serious coders.
That's strange, for me Tapestry is extremely natural, and you can accomplish a lot using very light touch.
Despite authoring Tapestry, I get to work with Struts (on a truly massive project) every day, and really hate it with a passion.
We are addressing some issues with adopting Tapestry... these are being developed right now as "Tapestry Lite" and will appear in the 2.4 release. You'll be able to get simple applications up and running much easier (no app spec, no page spec, just the HTML page with funky attributes in some tags) and transition at your own pace to more traditional Tapestry or whatever mix is appropriate for your project. We're making the cost of entry to Tapestry low... lower than JSPs, lower than Struts.
What handicaps most developers from other systems is that they try to map page-and-action development (Struts, particularily, or any other servlets and JSP) to Tapestry, which doesn't work. Apples and oranges.
Tapestry is about components, working together. The framework provides the basic services that allow you to build components of arbitrary complexity and hook them together easily while subtracting out loads of complexity.
Tapestry is doing all the busy work... moving properties around, providing names for forms and form fields, validating input, processing requests, building URLs... what you end up providing is the raw HTML templates, specifications to configure components, and small classes with short listener methods to handle user actions.
Meanwhile, the growing Tapestry team is giving us a real leg up... I'm busy coding while Neil is working on a *much* improved tutorial and Mind Bridge and pals are coming up with big new components.
Slashdot Mirror
Thanks! That was a key, early priority in Tapestry. Way back at servlet API 2.1 and JDK 1.2, Tapestry would still do a great job reporting exceptions (and still does). Tapestry uses a lot of nested exceptions, the exception reporter uses reflection to dynamically "dig out" nested exceptions, showing a stack of nested exceptions. Each exception is identified, along with message and any JavaBeans properties. The stack trace at the deepest level is displayed. In addition, full output of the various Servlet API objects is dumped out. I've had colleagues say that, everything else being equal, they would use Tapestry just for the exception reporting. The goal is to send the developer right the offending line without having to reproduce the problem using a debugger. Big time saver. Moral of the story: Tapestry is not demo ware, it is serious code developed by a serious coder for other serious coders.
That's strange, for me Tapestry is extremely natural, and you can accomplish a lot using very light touch.
... these are being developed right now as "Tapestry Lite" and will appear in the 2.4 release. You'll be able to get simple applications up and running much easier (no app spec, no page spec, just the HTML page with funky attributes in some tags) and transition at your own pace to more traditional Tapestry or whatever mix is appropriate for your project. We're making the cost of entry to Tapestry low ... lower than JSPs, lower than Struts.
... moving properties around, providing names for forms and form fields, validating input, processing requests, building URLs ... what you end up providing is the raw HTML templates, specifications to configure components, and small classes with short listener methods to handle user actions.
... I'm busy coding while Neil is working on a *much* improved tutorial and Mind Bridge and pals are coming up with big new components.
Despite authoring Tapestry, I get to work with Struts (on a truly massive project) every day, and really hate it with a passion.
We are addressing some issues with adopting Tapestry
What handicaps most developers from other systems is that they try to map page-and-action development (Struts, particularily, or any other servlets and JSP) to Tapestry, which doesn't work. Apples and oranges.
Tapestry is about components, working together. The framework provides the basic services that allow you to build components of arbitrary complexity and hook them together easily while subtracting out loads of complexity.
Tapestry is doing all the busy work
Meanwhile, the growing Tapestry team is giving us a real leg up
-- Howard Lewis Ship