Version 2 of Tapestry is now available on SourceForge. Tapestry is a true component object model for web applications, much in the way that Swing is a component object model for GUIs. Tapestry much of the heavy lifting in creating a web apps, such as constructing URLs, interpreting those same URLs and dispatching to user code.
Check out Tapestry
The Tapestry framework does virtually all of the heavy lifting in creating a web application. Principally, Tapestry is responsible for constructing all URLs, and for interpreting those same URLs and dispatching to user code. Coding interactivity in Tapestry is as simple as creating a listener method: a method invoked by the framework when a particular link is clicked, or a particular form is submitted.
Tapestry applications are constructed as pages of components. Pages are themselves components. Components contain parameters that define their behavior; these parameters are wired to other components, controller objects and domain objects via JavaBean properties, using the MVC pull model.
Components are easy to create, and many usuable components can be created by combining existing components, with little or no Java code.
Tapestry applications are extremely robust because the framework is responsible for constructing URLs, naming forms and form elements and doing most of the work in responding to links and form submissions. In addition, when something does go wrong, Tapestry features impressive exception reporting: a detailed exception page showing all nested exceptions, their JavaBeans properties, the stack trace at the deepest exception, and a detailed description of the servlet and HTTP request environment.
Tapestry supports team development in a number of ways. Tapestry provides a clean, Java approach to combine behaviors of components and pages. You don't load up a URL with query parameters, you invoke Java methods on Java objects. This eliminates many rough edges of web application development, places where an application can fail due to minor variations in naming.
Tapestry also supports HTML producers working with Java developers. Tapestry HTML templates contain a minimal amount of instrumentation and are still fully previewable in a WYSIWYG HTML editor even after being instrumented. This allows HTML producers to continue to operate on HTML templates as if they were static pages, which significantly eases overall development (such as minor formatting changes, or even signficant look and feel changes).
Tapestry supports internationalization. Component HTML templates and assets (such as images or stylesheets) may be localized, and Tapestry will automatically select the correct localization. In addition, traditional approaches (such as using localized properties files) may also be used. You can mix and match approaches even within the same component.
Tapestry has best-of-breed form handling, including an extremely sophisticated input validation subsystem. Form components are still components, and perform all the work of reading HTTP parameters and assigning values to properites (of your controllers or domain objects). Validation support allows you to control translation between Java properties and string values, and perform any number of validation checks such as date and number ranges.
The Tapestry distribution, available from SourceForge
contains pre-built JARs, tutorials, complete source code and extensive documentation. By downloading JBoss
as well, you can have a full J2EE application (including database, session and entity beans) running, using Tapestry, in under a minute.
In short, Tapestry is a revolutionary way to develop web applications, yet is still standards-based. Tapestry will significantly reduce your coding time and eliminate entire classes of bugs from your system.
Tapestry is licensed under the GNU Lesser General Public License.
Nice. But I don't like monster frameworks. I'm a fan of Freemarker
. Clean, simple, easy, powerful.
The question is: how much repetitive Java code do you want to write? Are you, and your team, including your junior developers, going to stay disciplined, organizes and consistent?
Freemarker and such are fine frameworks, and a step up from JSPs in most regards, but they only account for one portion of a the complete request-response cycle. Tapestry exists to complete that circle and eliminate all the code you will have to write in your "clean, simple, easy" framework.
Tapestry is also very well regarded as clean and powerful. After one "unlearns" the bad patterns of JSP development, it is also simple and easy.
What I would suggest is for you to build two similar applications using Tapestry and Freemarker and compare.
I already have; Tapestry includes the Virtual Library application. At one time, I had a JSP version of the Vlib that communicated with the same set of EJBs as the Tapestry version. Vlib/JSP was implemented using Sun model 2. Although less functional than Tapestry Vlib, it contained far, far more code. Performance was approximately equal.
I could have used Freemarker or WebMacro or XML/XSLT translation to implement response rendering instead of JSPs, but regardless, I would still have had to write all the servlets and code to extract query parameters and all the endless other stuff that is encapsulated inside Tapestry.
Instead, I let Tapestry build the URLs and dispatch directly to a listener method when a link is clicked or a form submitted. I let Tapestry components extract values for form fields when rendering, and set bean properties from form fields when forms are submitted. I let Tapestry manage server-side state and never think about HttpSession.
That are the points: "unlearn" and "complete cycle". Freemarker hasn't this approach and that's what I like.
Please qualify "like". In these kinds of discussions, we're trying to pin down advantages and disadvantages of various approaches. Tapestry provides a huge number of advantages, many of which aren't entirely obvious until you've played with it. I love to discuss Tapestry and will even own up to its limitations, but there's no point in attempting a discussion if your end of it is "I don't like it even though I haven't even looked at it."
What I like on Freemarker is the very lean but powerful scripting and the basic data models to move the data into the pages. You don't have to write many servlets. A general one is enough. The rest is simply business logic. If I look to your tapestry framework, I don't find it easy to use. There are a lot of preconditions and a big learning curve. You have also to write "components" to use in Tapestry. You state that one have to "unlearn" something and that you cover the "whole cicle". For me that sounds similar to the statements of the pure OO guys. I don't like monster frameworks (and Tapestry is one) because I have to marry it. I cannot use only parts of it without to understand the whole thing.
I don't like monster frameworks (and Tapestry is one) because I have to marry it.
Exactly. Once you build Tapestry components you are married with them. I think that tapestry re-use works only inside tapestry. What kind of reuse is it if you need a big framework to archieve that? I mean what happens when you exit web-development. Are your tapestry components still re-usable? I think they are not. So you need to use cut-and-paste re-use and duplicate the code in many places.
Can you tell me is this true:
Code you write for tapestry is reusable as long as you stick with tapestry? Yes, I mean those components.
Ok, you can write re-usable HTML components (tags) with tapestry. It's great, but I do not need this big framework to write re-usable HTML. It is very good that tapestry uses this kind of approach because competition is never bad... and yes... many projects that are not going to use tapestry are still able to examine it and rip off those parts that they find nice.
Struts and WebWork, on the other hand, have different approach. Instead on binding everything inside mega-components (?) those frameworks try to exit from HTTP/HTML world as fast as possible, so you are not held in any particular framework and you can use whatever you like to execute a particular task (for example execute JDBC queries, do some counting, connect to underlying EJB logic etc.). Also Struts and Webwork do not tie your presentation logic in anything (you can use jsp, velocity, sitemesh or whatever feels best). Tapestry has problem in that it tries to be too much. This is just my opinion, but I like thin web-frameworks.
I posted earlier one message, but did I get any answers? No. They were just talking about version numbers. That obviously was not my point (who cares).
Yes this is critic, but you can always ...
... prove me wrong!
I can't speak for Howard, maybe he has some miracle answer that will allay all your concerns.
Just sounds to me like you have already decided that Tapestry is crap. If its crap to you, fine.
Its not crap to me.
Geoff (The Tapestry contributor/Spindle developer)
AL: "Once you build Tapestry components you are married with them. I think that tapestry re-use works only inside tapestry. What kind of reuse is it if you need a big framework to archieve that? I mean what happens when you exit web-development. Are your tapestry components still re-usable? I think they are not. So you need to use cut-and-paste re-use and duplicate the code in many places."
TD:Yes, Tapestry components work only in Tapestry, (although you can call a Tapestry page from a page which doesn't use Tapestry and vice-versa), but remember that the Tapestry components are *only* web-user-interface components. They'll be interacting with your actual business logic components (whether these are EJBs, plain old Java etc.) Once you 'exit web-development' you are in a context where no web component is usuable. What code are you thinking would need to be cut and paste duplicated?
AL:"I do not need this big framework to write re-usable HTML."
TD: OK, Tapestry components are not just HTML. HTML is only half of the picture (in a web application). The other half is handling what a form does when it is submitted. Tapestry components allow you to reuse HTML without manually changing form names and input field names.
AL:"Struts and WebWork, on the other hand, have different approach. Instead on binding everything inside mega-components (?) those frameworks try to exit from HTTP/HTML world as fast as possible,"
TD: Tapestry hides the HTTP/HTML world much more effectively than struts does (I haven't used webwork), that is, the code you write has fewer dependencies on servlet classes than a struts action class does.
AL:" so you are not held in any particular framework and you can use whatever you like to execute a particular task (for example execute JDBC queries, do some counting, connect to underlying EJB logic etc.)."
TD: Same in Tapestry. Once Tapestry calls your listener function you can do whatever you like. Think of a listener function as being like an Action, but one where all the parameters in the request have already been processed, so all the parameters have been applied to their bindings (not just put into properties which match their names), and the submitted form/clicked link has been decoded so that exactly the right listener function has been called.
AL:"Also Struts and Webwork do not tie your presentation logic in anything (you can use jsp, velocity, sitemesh or whatever feels best). Tapestry has problem in that it tries to be too much. This is just my opinion, but I like thin web-frameworks."
TD: Tapestry must control the generated names for input elements in order to hide the HTTP request cycle from the developer. This is a crucial benefit.
What abstractions from struts do you use?
Has anyone tried wingS? The source code looks very similar to normal swing application which I think it is a great thing.
Does the component model in wingS similar to Tapestry?
Are there any wingS supporters willing to compare wingS and Tapestry here?
I haven't used any kind of framework but I am really sick of developing tranditional JSP because of the problems that has been pointed by Howard.
I went to the tapestry website and tried to download and get a hang of the whole component based web development which I have been waiting so long. But to tell you the truth - in addition to unlearning the things we know - we still have to figure out how to use tapestry
1. Develop starting from a scratch - say with TOMCAT without all the frills and thrills of Jetty or what have you.
2. Isolation of the tapestry framework with JEtty for download.
I seriously find the help and tutorials not even close to get a jump start specially when there is a steep learning curve. I am enthusiastic about it but without a good jump start - Its going to take me sometime before I start evaluating this stuff.
Also Could you provide a link for printing the complete tutorial???? I would love to read it when I commute. It takes me 70 min to complete my 7 mile journey and pass 3 cemetary and 2 funeral homes. (each way!!!) Would'nt I like to rather read Tapestry????
Thanks and Adios 3 Amigos of Tapestry!
I had been meaning to ask about Jetty. I thought I saw an older post from Howard (or someone) saying Jetty wasn't required and that Tapestry would run fine on Tomcat or any other servlet container with an updated JAR file (I think it was an xml parser).
From a quick perusal of the docs, I can't tell if Jetty is just distributed for convenience with the sample app, or if it is actually required for Tapestry to run.
I'm assuming it's the former, but can anyone who is already up and running shed light on a) if it's truly required, and b) if so, why?
I'm trying to get that piece of the picture a little clearer in my head.
No, Jetty is not required for most things. I am developing with Tomcat for my applications. I think the only peice tied to Jetty is the File Upload code, which I think will be re-written soon to eliminate that dependency.
There is a dependency on Jetty for decoding multipart forms. There is an outstanding bug to remove that dependency. Should be done in time for the 2.0.1 release (possibly this weekend).
Jetty is used in Tapestry because a) the developer (Greg Wilkins) is very responsive to questions b) its very, very easy to embed c) it is small d) it is very standards compliant.
To me, it is very important that you be able to download Tapestry and be running the tutorials (and, ideally, the whole JBoss/Home Page/Vlib thing) instantly ... even if the demo doesn't match your eventual deployment model.
BTW ... nearly 1000 downloads of Tapestry on April 1st. That's a start.
Jetty is absolutely not required. We've used it on Resin, WebSphere and Tomcat with no problems. And deployment to WebSphere was much cleaner than our attempts with Struts (and faster).
Thanks to all for the clarifications on Jetty - I figured it was mainly to package everything together into a cleanly installable demo. Good to know any "leftover" dependencies that were there (with multipart forms) will be removed shortly.
Tapestry components allow re-use that I have never been able to achieve using servlets or jsps. Tag libraries help but are little more than macros as far as I'm concerned.
I'm using Tapestry right now to build a very large app (>50 screens, >50 db tables) that will ultimately replace a legacy applet app that handles, without exageration, billions of dollars in telco-space business annually.
Do not underestimate the value of letting Tapestry handle URLs and form submission/listeners.
By using Tapestry and letting the mental overhead of using JSP and servlets fall away we are able to concentrate pumping out a well designed and built application.
"Tapestry release 2.0.0
> ... no significant changes
> since release 1.0.10."
It's a long step for a version numbering, but it is a small step for a software dev.
Is this pure marketing? Howard, are you afraid that your framework is not getting as much as reputation comparing to other frameworks (mainly Struts)?
What comes to monster frameworks... I think that tapestry tries to do too much for the user and I like to have more control over my software that I develop. You are praising that tapestry hides all the cryptic urls and form handling. Do you really think that it is cryptic? Almost every action I have build deals only with not more than 20 parameters and usually just a few. Mapping those to Actions is fairly simple (with or without something like struts or webwork framework). I have tried to read tapestry manuals, but it has not so far assured me. Tapestry is not very transparent. Yeah, you say that it is a black box... it really is. Also tapestry ties, if you ask me, too many tasks to itself... it has prensentation logic, validation, ... oh Howard has already told what it has.
What comes to reusable HTML markup. I think that the markup does not have to be very reusable. If you try to keep markup reusable you end up, sooner or later, with resricting designers freedom to create... I mean that if you have build your reusable tapestry component... you might like to reuse it, but then again, writing reusable components is very hard and if you really can make a reusable component you usually end up with component that is not usable at all. So you still have to modify your tapestry components.
Howard, please correct me if I have understood your concept wrong. My intention was not to bash tapestry but start a discussion. Maybe I have not understood tapestry at all.
I have to agree with most points for the moment.
I have built many apps on top of struts, and I do not feel I have to deal with a lot of 'cryptic' urls and doing plumbing to get the application working. In fact, with extensions like nested, dynamic forms, xdoclet support, struts becomes even better (and faster to develop with). I also looked at Tapestry, but I find the manual hard to read, and feel that real world usage could be hard (creating advanced components).
I think that the designer/developer split is a stupid thing (TM). Have you ever met a designer that knows nothing of HTML/JSP and creates superb applications using just clicking in dreamweaver? Drag'n drop developers, yeah right...
I too have built applications using struts. At the time, it fit our needs, and we took it a long way. However, I can't disagree more with your comments on the developer/designer split being stupid. We have a very talented graphic designers here, and yes, hey do know enough about JSP/Velocity to get by, but that is not what they do, and most of the time, their interactions with the scripting takes up more of our time than theirs. In researching Tapestry, I came across a phrase called 'sweating the pixels'. And what it talked about was/is the main frustration our GD's have dealt with. When using Struts or Velocity, in order to see what the finished page will look like, they must assemble the application, deploy it, and run it, just to see what the finished product is going to look like. They basically lose all the luxuries of WYSIWYG development. Aside from the other benefits(and there several) of Tapestry, this is the most powerful. I spent 30 minutes or so with one of our GD's here, and he was giddy at what I showed him as I redesign one of our smaller apps using Tapestry.
Bottom line for us is this. We have GD's and we have developers, and I don't want them to necessarily have to know each others job to get things done. Tapestry is the best framework I have seen that offers this sort of seperation.
>> ... no significant changes
>> since release 1.0.10."
>It's a long step for a version numbering, but it is a small step for a software dev.
>Is this pure marketing? Howard, are you afraid that your
>framework is not getting as much as reputation comparing to
>other frameworks (mainly Struts)?
I wouldn't get hung up on this. I believe that 1.0.10 was a release candidate for 2.0.0.
I found the learning curve for Tapestry quite steep, but not too much steeper than other frameworks. There definitely was a "click" event in my head where I realized what Tapestry was providing me something I needed and have not seen elsewhere.
You "believe" that 1.0.10 was a release candidate? You had a "click" event where the light bulb went off in your head and you suddenly understood Tapestry?
You're listed as one of the Tapestry developers at the SourceForge site. You either were marginally involved, or your comments (which lead the reader to believe you're simply a user of the framework with no vested interest in its promotion) are intentionally misleading.
I'm checking Tapestry out, but I have to say that I'm already wary, given your comments and Howard's ("Geoff Longman's comments are right on the money" - Howard acts like he doesn't know who you are, when in fact, he should, since you're listed as a member of his development team).
This comes off looking like a coordinated marketing effort, and leaves the reader wondering about the others who are singing Tapestry's praises. Then again, there may be a simple explanation for it, and it may be a misunderstanding on my part ;-)
Please tell me I'm wrong - this framework does sound intriguing, but in the interest of full disclosure, I'd like to know what your relationship to the project is.
I wouldn't get too worked up conspiracy theory-wise. I've contributed to a number of projects that I found to be useful and didn't feel that I was immediately disqualified from praising the projects subsequently.
OK - thanks for the perspective here. I don't think it's a bad thing to sing praises, even if you've worked on it, but to me it looked bad when I saw that a couple of the posters who most strongly supported the thing were also its developers, and didn't disclose that.
But that's why I asked to be corrected ;-) Maybe this is a common occurence. But I am also looking for unbiased responses of "lay" developers to get their experiences, and if you work on a product, you know it inside and out, and of course it's easy to use, etc.
I guess I'll take this stuff with an *additional* grain of salt ;-) The framework concept does look promising!
The reality is that many folks who've used Tapestry as "lay developers" have come up with reusable components or other extensions (or even a desire to help with bug fixes). A "developer" on SourceForge is someone with CVS access ... regardless of whether they are checking in one file or hundreds.
You "believe" that 1.0.10 was a release candidate? You had
>a "click" event where the light bulb went off in your head
>and you suddenly understood Tapestry?
Of course I know who Geoff is ... he's been working on the Eclipse plugin for Tapestry. So what we have is someone who only knows me through Tapestry, who is so taken with Tapestry that he's spent weeks developing a plugin for it, and who is stepping up to the bat to participate in these discussions.
In the open source arena, you don't get support like that because of your good looks, you get it because you have something substantial to offer.
Absolutely - I just wanted to know what his role was. I'm new to this stuff and looking for a good framework (we're already prototyping with Struts) and this looked intriguing, and I was happy to see some good comments about it.
I guess my suspicions were aroused when I saw that a couple posters were developers, since I was looking for unbiased feedback. But I surely understand your explanation - Geoff thought this framework was so great that he decided to become involved. That's all I was looking for. Thanks for the response.
I'm not a Tapestry developer, but I am impressed with it. The differences between Tapestry and struts/JSP that *I* see as key are:
- Tapestry makes it easy to make reusable, parameterized components. I know someone (not you) in this thread said that they believe reuse is not important -- I think that reuse (writing each thing in only one place) is what software development is all about.
- Tapestry is round trip -- it handles processing of form submissions transparently (i.e. the page author specifies the input fields and their bindings in one place, and Tapestry does the rest -- you never need to see the HttpRequest)
- Tapestry has very nice error handling/reporting. This saves a lot of time.
- Tapestry seperates HTML and Java much more effectively than JSPs.
Yes, Tapestry is a larger framework than struts/JSP. I find this an advantage. I have worked on a large project using struts/JSP, and have ended up with a mess. I'm sure that there are better ways to use struts/JSP, but we didn't find them. Finding them would involve creating standards and a framework to express the standards, Tapestry has already done this.
I have used Tapestry enough to know that it would have been a much more productive solution than struts/JSP for that project with that team.
Perhaps the people who find Tapestry too large are accustomed to creating web sites with a small amount of dynamic content rather than web applications?
Do a prototype with Tapestry and compare it to your struts prototype. Ask some questions on the Tapestry mailing list if there are aspects of your prototype which seem awkward.
Tom, thanks for the reply.
I am facing exctaly the same issues you mentioned with Struts - having to create a framework of standards to keep the thing organized. Not that stds. are bad <g>, but I know what you mean - Struts has the potential to become unwieldy (well, now I know that the potential has been realized, and it's not just a theoretical concern of mine).
The other issue you mentioned is simply that of productivity, which to me is by far the most important factor. If I can get my hands around this thing, and get some of the less experienced developers up and running (we have a mix of platforms here we're migrating from), then mission accomplished.
I will consider each of your points at the "high level" as I am digging into Tapestry. Thanks for the guidance.
Since you are looking at the sourceforge - have a look at the forums - somtime around November 2001 you'll see a post with subject line "dumb newbie question" - that's me.
Just before christmas I had the "click". My company is embarking on a project and I'm the guy who would be responsible for the presentation layer. Now, at christmas I was of the mind to push tapestry as the framework we would use.
But one thing was holding me back. No IDE support. I hate editing xml files. Yes I know there are tools and I have some very good ones. My wish list at the time would be to have a tool that was Tapestry aware. Sadly none existed at the time.
Simultaneously I was looking at Eclipse and its Plugin Development Environment. I used to do Swing before the web stuff and it was attractive to me try building a Plugin.
It was not a great leap to decide to build a plugin for tapestry. I was a week into it before I even told Howard. Having IDE support is always a good thing and while I was writing it I was asking a lot of questions and even suggesting some changes to Tapestry that would make my job easier. Howard added me as a developer.
If you look closer at the page on SourceForge you'll see that Tapestry has been around for years. I hardly qualify as "one of the developers of Tapestry". As far as I'm concerned there is only one developer and its Howard.
I like Tapestry a lot. And if I get a chance to plug it I will.
as for the release candidate thing I was assuming this as Howard has been talking about 2.0.0 for at least a month.
You will notice that 1.0.9 and 1.0.10 came out reeaally close together.
Geoff - thanks much for the explanation, and sorry if I got a little too worked up there (apologies to you, Howard and David <g>).
I was very interested in this product from its description and posts, and probably because as suspicious as I was exicted about it ;-)
I've just finished downloading it and am eager to check it out. As I mentioned to Howard, we're prototyping with Struts, and I'm in a similar position to yours in that I need to choose a presentation framework.
Although Struts is cleanly designed, I can see it becoming rigid and difficult to maintain as a project grows. Plus, we have some developers here who are new to Java, and we have to deal with the same presentation issues (we ideally want to be able to edit pages with a WYSIWYG tool without having to redeploy, etc.). That's why I was so excited about the component model you guys have described, so I guess I was a little confused when I saw developers posting. I have not had the opp. to contribute to an open source project (yet) and just had to ask about the roles, so I understood what was happening.
Thanks to both of you for taking the time to explain it - I'm looking forward to digging in. It's not too late for this gig to change direction!
No worries. This is the first open source project I've been involved with in any fashion - so its all new to me too.
as a regular reader of the tapestry mailinglist I know that Geoff is the developer/contributor of an upcoming eclipse plugin for tapestry (which hopefully will make development with tapestry very simple and fast). Not more and not less. And by the way, tapestry ist really good and very well documented, I have really been looking around for a long time for such a object oriented framework, and there is nothing else around.
Roberto - thanks for the note. I am in the same boat - looking and looking, and not terribly happy with what I'm finding so far. Struts is a good start, but still not quite there yet.
I'm hoping Tapestry will be something I can get up and running quickly, so I can give a good overview/Struts comparison to developers and mgmt alike. It sounds like that's the case - very promising.
Tapestry 1.0.9 and 1.0.10 were release candidates for 2.0.0.
Tapestry release 1.0.0 was last may ... since then the framework has added so many significant features that I felt the time was right to give it a new major release number. Sure, there's some marketing there.
The markup ABSOLUTELY has to be transparent. My background and Advis and Primix was to produce graphically striking, highly useable, scalable web applications. We had graphic designers who knew little HTML, HTML producers who new very little Java, and Java developers who couldn't choose a decent color if their life depended on it. It is VITALLY important that these people be able to work together without tripping on each other.
If you are doing simple, ugly presentations for yourself, or your intranet, then these issues aren't so bad. But very few of us have the luxury of working as a one-man shop.
Normal JSP development is a one-way process; once the static HTML page is turned into a JSP is becomes a frightful mess to make further changes to layout and look and feel.
In terms of reusability: I've created a mega-component called the Palette as an example of just how far you can push reusability. See this article at OnJava
The Palette can be and is reusable. In fact, it appears in the Workbench demo, and is used inside the Virtual Library. Through a mix of parameters and stylesheets, it blends perfectly into both applications. Yes writing a completely reusable component can be hard.
I'd also like to remind you that I have the benefit of using both approaches to web application development. I've been developing web applications using servlets since 1998 using servlets and JSPs and, for the last agnonzing months, Struts. I can see specifically in our organization exactly how Tapestry would reduce coding effort and bugs. I see our creative people having to jump through hoops to make minor layout changes. I see how unnecessarily complicated it is to integrate my pages with tools provided by other team members. None of this has to be, and the solution is Tapestry.
AL: "I think that tapestry tries to do too much for the user and I like to have more control over my software that I develop"
TD: Fair enough if that's what you like, but the addition of abstraction (that is, the removal of details you need to worry about) is something which enhances productivity. Tapestry does this successfully.
AL: "You are praising that tapestry hides all the cryptic urls and form handling. Do you really think that it is cryptic?"
TD: I think that making sure your form is generated with appropriately named input tags, and then mapping the values these get in the request to your Java properties is cryptic, especially once you start using reusable components.
"Almost every action I have build deals only with not more than 20 parameters and usually just a few. Mapping those to Actions is fairly simple (with or without something like struts or webwork framework)."
TD: I'm not certain what you mean by 'mapping those [parameters] to actions', could you explain?
AL: "I have tried to read tapestry manuals, but it has not so far assured me. Tapestry is not very transparent. Yeah, you say that it is a black box... it really is."
TD: Try writing a small Tapestry app, or reading the source code for the sample app. Tapestry has documentation which is tons better than struts (IMHO) but it does take *using* it to really understand how nice it is. Yes, you can treat Tapestry as a black box, which is good, because it exists to hide details.
AL: "Also tapestry ties, if you ask me, too many tasks to itself... it has prensentation logic, validation, ..."
TD: Well, Tapestry needs presentation logic, that's what it is there for. The validation you can take or leave, but if you want to be able to mark particular input tags as having failed validation, then your presentation logic at least needs hooks to your validation. In Tapestry you can write the actual validation functions yourself, and can do page-level validation however you like. What other tasks that Tapestry does do you think it shouldn't? (the '...' in your post)
AL: "What comes to reusable HTML markup. I think that the markup does not have to be very reusable. If you try to keep markup reusable you end up, sooner or later, with resricting designers freedom to create... I mean that if you have build your reusable tapestry component... you might like to reuse it, but then again, writing reusable components is very hard and if you really can make a reusable component you usually end up with component that is not usable at all. So you still have to modify your tapestry components."
TD: I think that having reusable markup is a good idea. It cuts down on the maintenance required when you want to change the way your site looks -- that's why style sheets are good too. One of the principles of good software engineering is that each concept should be expressed in one place. Yes, getting the component right, having the right parameterisations available for instance, is not trivial, but that doesn't mean it isn't worth being able to do this. I'm assuming that you write JSPs? Do you avoid custom tags all together?
Hope these comments/questions help.
Try Tapestry. You'll like it!
Try Tapestry. You'll like it!
I’m not so sure. New frameworks come out almost weekly, simply there is not enough time to try them all.
is a framework with proven design, wide user base and solid track record. If your project should fail, it’s definitely not going to be because of Struts.
So far, I have not heard anything that would make me want to switch. Complexity argument does not do much for me, since I believe that Struts is well within reach of an average developer.
Interesting idea though, but I wouldn’t say that it’s obviously better or equal to Strust.
Interesting idea though, but I wouldn't say that it's obviously better or equal to Strust.
Having used both I can say that from where I stand Tapestry is obviously better.
It is an interesting question: What is the best way to communicate the characteristics of a framework in a way which is compelling, without requiring that the reader spend long enough to use the framework?
Is there a good example of a 'best practice' struts app around?
TD: Hope these comments/questions help.
Thanks... finally I got some answers and yes I had some false statements or thoughts about Tapestry and thanks for correcting those.
TD: Try Tapestry. You'll like it!
Maybe I should dig deeper in Tapestry, but I'm still not sure (that's my problem) if it's going to be worth it. As someone had already said, there exists so many frameworks in java world, that it is quite hard to make decisions on what is best or what is best for something in particular. Yes... you can try them all if you have lot's of time (to waste). Still you also may want to learn many more things for example databases, sql, design patterns, ejb, jdo, xdoclet, ant, jaas, the list is almost endless. So you have to decide if you are going to use a framework and what fits best on you... also depending on your skills. Many developers have wasted so much efforts on something they are not going to use ever. The frustration on learning framework is in that when you learn some new framework you will like it, but you will most likely also hate it... then you look something better (for example Tapestry)... can you be sure that this does not end up with this same frustration? No you don't, nobody can.
I think that there are many java web developers out there that are looking for somekind of framework. Many of them do not have very good knowledge or experience in developing webapps with java (count me in). So they think that some framework would help. And yes it will, but deciding on what boat you jump is not very easy (it can be, but then there is a great chance that you jump on a wrong one). You cannot push those frameworks to their limits because of lack of experience. Of course at start all these frameworks look good and they seem solve the things you want... still you cannot know if they are going to work in the long run.
Aapo, let me appologize for losing my temper.
You are right, there is an investment of time with no guarantee that you will find any framework is the cat's meow.
Perhaps its not the right time for you to look closely at Tapestry. Early adopters are a strange breed, I know being one of them!
That's fine, Tapestry will still be there if, at some point, the features offered start to look intriging to you. And it'll be even better whenever that time comes!
At this point, I don't know that using Tapestry makes one an early adopter.
Tapestry has been used on a number of succesful projects by myself and others. Releases have been stable and there's adequate documentation.
Tapestry may not be getting the recognition we think it deserved :-> ... but anything since about 1.0.2 isn't really early adoption.
AL: "Maybe I should dig deeper in Tapestry, but I'm still not sure (that's my problem) if it's going to be worth it. As someone had already said, there exists so many frameworks in java world, that it is quite hard to make decisions on what is best or what is best for something in particular."
I haven't tried every framework, so I can't say that Tapestry is the best.
What I can say for sure is that using Tapestry has opened my eyes to at least *some* aspects of what the perfect web application framework would be like, and that even if my next project said 'thou shalt use struts, for no soul hast been cast from heaven for using jakarta' I would have a much better idea about what custom tags and action utility classes I needed to write to make it work for me.
I'd still want Tapestry though :-)
I'd recommend to anyone who thinks that they may still have something to learn that they devote one or two days to converting a few pages of their latest app to Tapestry. I think you'll find its viewpoint worthwhile, even if you don't end up using it.
I agree that there are infinite things to learn. Which is both a curse and a blessing...
Your post, among others, has highlighted the need for some sort of in-depth analysis of the large number of web frameworks available. To date there is very little as far as comparisons of different products goes (aside from marketing material for each framework).
I began working on such a project a few months ago as part of a presentation I did for my local JUG. Essentially I took six frameworks (Struts, WebWork, Turbine, JPublish, Melati, Barracuda), downloaded each, attempted to install their example applications, browsed through their documentation, and tried to understand what the advantages and disadvantages are for each. Since my presentation was only an hour long I did not research each framework to the depth which will ultimately be necessary. However, even though I only scratched the surface it was very easy to see that there is a lot of common ground among frameworks, but at the same time each framework has its own distinguishing features which sets it apart from the rest.
Now, I would like to take this to the next step, but clearly it will require a lot of time. Thus, I am wondering if anyone else is interested in assisting with this project? I believe that the easiest way to evaluate the frameworks on level ground is to come up with a simple application which demonstates the main features that are exepected from developers when choosing a framework. These features could include:
- Form handling (validation, execution of business logic)
- Access to business objects (EJB or direct to database)
- Ease of use from both programmer and designer POV
I am sure there are other items which deserve to be on this list.
Thoughts? Is anyone else interested in working on a research project such as this?
Are your results available anywhere? If not, are you willing to do so? Would be a nice read.
The results which I have were presented to my JUG verbally with the aid of a Power Point presentation. Thus, it would probably not make for very interesting reading. :-) However, I would like to take this project much, much further, which is why I wrote my previous post. When I do finally get to the point of being able to publish results I intend to do so on the web so that others will be able to use the results to assist in selecting a framework.
FWIW, I authored and develop the JPublish framework. However, rest assured that I will attempt to avoid bias towards any framework, including JPublish. The goal is to provide a good source for making an informed descision on which framework to use, even if it is not my framework.
Perhaps it would be interesting to have two perspectives for each framework: the first would be a "best-practices" perspective written by someone intimately familiar with the framework, whereas the second would be from someone who has little to no experience with the framework. Thoughts?
We have an old webapp written in plain-vanilla jsp/servlets, which I'm interested in converting to a framework. So far I've had a brief look at Cocoon and Struts; Tapestry is next on the list simply because of the praise its gotten in this thread. I'd be interested to work with you on a "framework review" however. You can reach me at twheeler at recursionsw.com if you'd like to discuss further.
The enhydra people have done some very good
comparisons of barracuda with other frameworks.
One such article is
Barracuda looks very good to me, but I haven't
looked at tapestry yet.
There definitely are a lot of these frameworks!
While the factual information provided in the Barracuda vs. Struts doc is good, the opinions provided within are obviously biased towards Barracuda.
Personally what I would like to see is an actual application written using as many of the frameworks as possible. Then it would be possible to compare the actual application code as well as the process which is required to write that code, while at the same time providing a more feature to feature comparison.
Is a JavaBean not a component because you can only use it inside a Java VM? Is JTable not a component, because you can only use it with Swing (and not Qt, or ActiveX)? Is an EJB not a component because it must run inside a J2EE server, and not on .NET?
In each of these cases, a software substrate is necessary to define the boundaries, responsibilities and context for the component, especially in terms of a component's ability to interact with other similar components.
You've said that creating reusable HTML components is hard, so hard that its not practical. I have many counter-examples using Tapestry, because Tapestry is *designed* specifically to facilitate reusable HTML components.
I have found that using Struts and JSPs, even horizontal reuse (creating common components that are tied to a single application) is overly difficult; difficult enough that it takes a fairly senior developer to pull it off succesfully.
However, the users of Tapestry out in the field have found it easy to create such components; it's often the first thing they do.
Vertical inheritance (creating components that are usable in any application), like the Palette
is more difficult, but Tapestry provides the tools to facilitate even something as ambitious as this.
How does Tapestry compare to the Struts framework? Why would someone who has been successful using Struts move to the Tapestry framework?
Tagged onto the end of the recent WebWork 1.0 announcement was several Tapestry vs. Struts. vs. WebWork questions.
Struts is a thin wrapper on top of servlets and JSPs. Combined with the Struts tag libraries, some things are a bit easier ... for instance, you can assemble your query parameters as a Map in your Java code, and Struts will combine them with a Struts action you specify to form a final URL.
However, you still have to name your Actions, name your forms and fields and do lots of work to tie this together. I'm working at a new company and we're finishing a 1.0 release using Struts (talk of moving to Tapestry will be coming soon) ... and its just a back-breaking amount of work. In addition, we have many junior developers who simply aren't up to the challenge of creating re-usable components as JSP tags, and creating re-usable components in general is very, very hard to do properly.
If we were using Tapestry instead of Struts, we could build the application using about 15 - 20% of the code and it would be far more robust to boot.
Struts, the framework, has the opinion that URLs are so complex, only the human developer can understand how they, and everything on a page, are related. Tapestry takes the opposite view ... it understands all the relationships between a page, the components on the page, and the links and forms rendered in HTML by those components. Tapestry does all the work of building URLs and dispatching incoming requests when links are clicked and forms submitted.
Struts, and servlets, have a very "flat" dispatch model. Request => Action == user code. This results in a fairly "weak" notion of page, since one Struts "page" is several Struts actions plus a JSP to render responses, plus lots of request attributes for passing data between Actions and JSPs.
Tapestry uses a nested dispatch model, that understands that the page is composed of reusable components that may themselves contain components. The URLs generated by Tapestry already take into account this kind of complexity, even though simple applications don't take advantage of it. Yet, when you build components containing components containing forms ... everything still works.
Incoming URLs contain the identify of the page and the component within the page; this component (a Form or a Direct or an Action) is notified that it was activated and it finds a listener method, set as a parameter, which is provided by user code. You write none of the dispatching code ... you just write the short listener method.
Tapestry ends up like a very flexible skeleton ... when those late-cycle changes come ("we need to add a search form to every page") you can handle it easily, without breaking the existing application and dispatch model.
Meanwhile, Tapestry is extremely "hookable". It's designed to be extended to address special cases. Tapestry doesn't wall you in, there's always a way to cleanly work around any limitations in the default implementation.
My problems with Struts are about scaling and complexity. Take form beans; its nice that they can validate themselves, but they are then tied to a single, specific Action, even if they are used in many places. Struts can help you create forms, but doesn't help you if there is a loop inside your form. It can't do complex validations for you when the form is submitted.
Struts tags don't have an analog to Tapestry's "informal parameters" ... if the tag doesn't define an attribute you need, you can't use it. Tapestry allows you to specify any HTML attributes you want (though it filters out attributes that conflict with attriute needed by the component).
Struts uses a global file for configuring all your beans, forwards and actions (you can use a patch to allow multiple such configuration files).
In Tapestry, each page and component gets its own component specification. This allows pages and components to keep their implementation details private, just exporting parameters or properties to allow interaction with other parts of the application.
Geoff Longman's comment is right on the money ... Tapestry takes care of tons of stuff so you don't have to; instead your concentrate on your particular application, without re-solving all the problems everyone else has already had to solve for their applications.
Tapestry also gives truly excellent developer support at runtime. The Inspector allows you to see how a running application is constructed. The Exception page does an amazing job of describing, in great detail, what went wrong ... 90% of the time, there's no need to restart the application and use a debugger. Tapestry has been designed by a seasoned developer (me) to be developer friendly. And with Geoff's upcoming Eclipse plugin, that much better!
I was an early Struts supporter and am currently using it in pretty large site (distributed application portal). Struts works well for small and simple sites, but we have run into problems scaleing it to our large site.
As Howard stated, it really becomes a pain to manage all the interconnected links and application dispatches. We've actually found that it tends to inhibit reuse becuase of its flat dispatch model. We are currently researching Tapestry for the next version of our site. On review alone, it seems MUCH more capable for RAD web development--while maintaing an MVC architecture no less--than tools like Struts or WebWork.
I've said it before and I'll say it again... You owe it to yourself to take a serious look at Tapestry. It's the most exciting model in Java web development I've seen in a long time. It really allows you to build applications--not web sites--that "execute on the web." Very cool stuff.
Thanks for these thoughtful posts. It provides developers with the right kind of information to make decisions about frameworks.
Struts definitely has a lot of mindshare right now but there's definitely room for all the frameworks too. I am sure they can coexist and maybe even learn and improve from each other.
Now only if someone could give us an unbiased and dispassionate review of .Net v/s Struts/Tapestry/Webwork :).
Any such review will of course be drowned out by all the noise about Sun v/s Microsoft, Microsoft v/s Open source and all the other flames,trolls and abuse which are usually provoked by anything Microsoft.
I stumbled across this presentation a few weeks ago. It's based on the very, very ancient Tapestry 0.2.3 (which predates a lot of useful things, like modern template parsing, listener methods, and validating text fields).
Woops. Looks like that link is no longer valid.
I think the korea link is broken - I can't get to it anyway.
Since I haven't used Tapestry extensively, I can't give you an in-depth review/comparison between .NET/Struts/WebWork and it. However, I can cay that it is much closer to the ASP.NET model of web development (and I'm not talking about web services, C#, COM, or whatever here—simply the STYLE of web development) than Struts or WebWork. What is the difference?
Well, Struts and WebWork both follow a metaphor of a URL that maps (through a central dispatcher) to some application logic (an "action"). This logic is responsible for doing something and then sending the request to some "view" for output. So, many different actions may be required to process or update one page. It's up to the developer to try and plumb these actions together into a coherent "application". There's no listing someplace of all the components (or "actions") required to complete a particular operation. This makes management and change difficult.
On the other hand, Tapestry treats everything like a component. A component is a black box that knows how to do "something". It can respond to events, fire events, and change state in other components. Components can be composed of many other components to define new functionality. In fact, a Page is just a component that contains all the components needed to do its thing. This is very similar to developing VB applications with a collection of intercommunicating components working to solve some problem. This is probably the reason that Microsoft chose this model for ASP.NET--it allows all the VB developers to port their skills in RAD windows development to developing apps on the web. The cool thing about Tapestry (and ASP.NET) is that the developer is thinking about the application, not all the plumbing required to make it work in a web context--the framework hides the fact that it's a web site running the application. A component simply responds to an event, it could care less if that event was fired from a form submit, a link, or even another component. It really is a new and exciting way to think about web development. Sure all the regular GUI guys will say this is old stuff, but it makes developing web apps much faster and easier to maintain. It's kind of liberating when you realize that you don't have to worry about generating the right URLs or somehow persisting the workflow and application logic--Tapestry does it for you. You just write simple JavaBeans to do stuff. What could be easier than that?!
Don't let the fact that it's similar to ASP.NET scare you. It is a compelling way to look at web development. The ideas are revolutionary simply because they are, not because Microsoft or anyone else has endorsed them. I actually see this as a great way to compete with MS because the Java world now has access to the same advanced and simplified development models as all the MS guys. Now we just need good IDE support (it's being worked on--just hold on).
Don't let the fact that it's similar to ASP.NET scare you. It is a compelling way to look at web development. The ideas are revolutionary simply because they are, not because Microsoft or anyone else has endorsed them. I actually see this as a great way to compete with MS because the Java world now has access to the same advanced and simplified development models as all the MS guys. Now we just need good IDE support (it's being worked on--just hold on).
As a former VB developer (gasp! <redirect all statements about VB not being a language,not OO, a toy etc. to dev/null or the recycle bin>),I can relate to this model. VB's strength and success came from the fact that it hid away many of the complexities from the developers and in return gave you about 75% -80% power of VC++. This was more than enough for most front ends. Plus a good IDE and the huge market of third party add ons("components") made it a compelling choice for many things.
Good IDE support will go a long way. How about a Tapestry component repository (like CPAN)? Does that make sense?
Tapestry does *not* require that any part of the JAR be unpacked. Packaged assets, assets on the classpath, will be exposed to the client web browser in one of two ways. Either the asset service will dynamically access the asset and provide it to the client as a byte stream or the asset will be copied out of the classpath and to the file system (where it is visible as a static file to the web server).
So, more so than (say, WebObjects) it is completely reasonable to easily use and package Tapestry components.
The Tapestry distribution is split into two frameworks. com.primix.tapestry-x-x-x.jar contains the main framework and components. net.sf.tapestry.contrib-x-x-x.jar contains additional components, such as the Palette.
I can't sing enough praise for the Inspector and Exception handling in Tapestry. I *hate* looking at exceptions thrown by JSPs and I hate even more looking at code that a container has generated for JSPs.
Go to http://tapestry.javanuke.org/tutorial/workbench
Click the Exception tab (on the right). Then click the link. What you get is the glorious exception report of which I was referring to earlier. Basically, its pretty much all the information you would collect with a debugger and almost always directs you to the specfic object, method or specification and line that is causing a problem.
The Inspector is another beast; its a mini-application you can include in you application (while developing it). It allows you to see the running Tapestry application; specifications, properties, templates and more.
It also lets you view properties of objects.
It even lets you see a hex dump of the application engine (the single object Tapestry stores into the HttpSession).
Oh, and manage your Log4J categories on the fly. Can't forget that.
Click the gear icon in the lower-right corner to raise the Inspector.
Does anyone have idea about how much afford is required for a beginner to build a website like http://tapestry.javanuke.org/tutorial/workbench
The tutorial looks very impressive but also difficult.
By my quik count, the work bench app has 11 .java files
Geoff - Tapestry contributor
Does anyone have idea about how much afford is
>required for a beginner to build a website
>The tutorial looks very impressive but also difficult.
I put most of it together in just a couple of days. The hardest part was choosing colors, creating those little tab images, and tweaking the CSS. Also it was built specifically to allow new pages to be added easily (the Border component, which draws the navigation tabs, has a .properties file that identifies which pages are on the tabs).
Did you look at the code and find that difficult? Or are you just guessing that building the workbench was difficult? I think you'll find that there's very little code in the entire Workbench. Most of the specifications (except, maybe, for the Fields page ... since it has many fields that have lots of parameters to be configured) ... anyway, most of the specifications are very short as well.
The Workbench is the little chunk of ice above water ... Tapestry is the huge iceberg below.
I think there are two major problems with Tapestry right now:
1. Documentation. It is there but not sufficient in my opinion. The tutorial is out of date and there aren't enough examples. Even suprising is the fact that there aren't any user groups (or at least I could not find one) and no place to get help if you get stuck. This makes the learning curve even more steep.
2. Performance. Regardless of what is claimed, a framework like Tapestry will be slower than pure Java/JSP code. It is because of whole lot of introspection and running off of meta data. It would be great if an objective comparison (with actual numbers) is made b/w a pure Java/JSP app and same app in JSP. I don't know how Tapestry behaves under heavy user load.
Addressing the above two issues would make Tapestry a even better framework.
Great review...But is there any possibility to use Tapestry as a view technology with Struts.I know that it could sound utopic, but is possible a website based on Struts and use Tapestry as view component?
Tapestry is the best solution to the presentation tier and it provides a clean separation of content and developer code.
First, I extended it for WAP support, then I developed several WAP components and finally I developed a complete email application for WAP in a record time.
My main concern is the tool support: One of the things that rub me about Tapestry is that our designers using Dreamweaver (or other WYSIWYG tools) get nothing but a mess of <jwc> tags.
We have plans to use Tapestry in all future projects.
...Tapestry is backwards compatible.
I uses attributes a la:
<input jwcid="insertRealInputHereComponent" >
These add no complexity in tools like Dreamweaver.
David Solis - you're a Tapestry developer too, just like Geoff Longman! Of *course* you're going to use Tapestry on all future projects.
I understand you guys need to market this thing, but it would be valuable to other developers if you were upfront about your roles, instead of posing as developers who have "discovered" Tapestry and are blown away. It's always good to know that there are multiple people who are willing to support the product and answer questions.
I suggest that anyone reading future posts on this thread that recommend Tapestry check the reply against the SourceForge site to make sure that the "recommendation" is not coming straight from a Tapestry developer.
Again, I will qualify this with a "Maybe I'm wrong, and maybe I don't understand the roles of the people listed on the project" - but they all say "developer" on the SF site. If I'm wrong here, please correct me, for the benefit of all reading this thread and consdiering using this product.
I don't know why people are making such a big deal because some of the Tapestry developers (btw, I'm not one--just so we have "FULL DISCLOSURE") are promoting their product. I hope that they would promote it since they're working on it. Why wouldn't you use and promote something you work hard on to provide for others? I mean, Rickard gets on here and sings the praises of WebWork vs. whatever and no one throws a fit--and he's OBVIOUSLY biased. Sheesh, ease up a bit.
As a 'lay developer' using Tapestry I can only recommend it.
We have build a CMS based on Tapestry plus multiple sites that are now powered by it.
Thanks to its component architecture, we are able to publish any kind of our metadata-driven business object with just a handful of generic highly dynamic 'pages' using customizable components.
Only by parametrizing the component descriptors (aka .jwc files) plus the HTML-templates, we have been able to deploy different sites, without any(!) non-standard Java coding. Everything is a generic, highly reusable Tapestry component.
All business logic is encapsulated in business objects and services, so there is not really much logic in the presentation layer besides the navigation parts.
The learning curve is not flat, but is really worth the effort. If you need to bring a dynamic web-app to the browser Tapestry offers many predefined and stable components to build on.
We have gone with Tapestry and we will continue to use in the next couple of projects needing a web-interface, too.
Only my 2 cents.
Are any of these applications public? I'd love to see one of them in action. Perhaps a Viewlet?
Let me clarify this:
Tapestry was developed by one person, Howard Ship, with small contributions (ideas and code). This fact has advantages and disadvantages but this is other story.
I modified only two classes, added three classes and one example to provide a basic WAP support.
I'm a real Tapestry user.
We evaluated several presentation frameworks such as JSP, Hammock, WebMacro, FreeMarker, XMLC, Struts, Maverick and Swinglets; found that Tapestry is the best for our purposes. The learning curving was easy because we were WebObjects developers for almost four years.
David, thanks for the clarification. And please forgive my earlier rant ;-) I happened on the developer page when I was downloading the thing, recognized some names, and got the wrong idea.
Is there a comparison of the functionality between Tapestry and WebObjects? (http://www.apple.com/webobjects
WebObjects has a HTML designer, and supports both Web and Java clients. It also includes an object persistence layer(from NeXT).
I only have experience with their sample application, and found it quite interesting. Will Tapestry be a open-source alternative of WebObjects?
There's a bit of WebObjects heritage in Tapestry. I had used WebObjects and EOF of and on for a while. Tapestry started as a mind-exercise to figure out how WOF does its thing.
Internally they are quite different. WOF does a few things I wish Tapestry did, and Tapestry does many things right that WOF doesn't ... specifically in terms of ease of deployment, use of XML to define components, real integration with Java, better form handling, and much lower server resources.
I've heard of some folks using EOF with Tapestry.
I'm also working on a O/R mapping tool tailored for web application development: Sabertooth
In all the years I developed Applications for the web, the most impressive Product and in my opinion the best I've ever used is WebObjects by Apple (original development by NeXT). It basically consists of two Frameworks: WOF and EOF. The scalability of escpecially the EOF (Enterprise Objecs Framework, handles data and persistence), it's elegancy and superior programming model is unmatched. WebObjects was more complete, more powerful and more scalabe years ago than EJB, JSP etc. are today.
The only bad things about WO I know of are a quite steep learning curve and that is a proprietary technology. Until about 1 1/2 year ago it was quite expensive ($US 50.000), but sells now for 699 bucks. Another disadvantage is that it's an Apple product. Don't get me wrong: I like Apple Computers and their OS very much, but try to sell a technology from Apple to a hardcore IT man. Those guys usually think Apple computers are toy for grahpic designer (which is definitely wrong).
The first time I heard about tapestry was 30 minutes ago. If tapestry is inspired to a degree by WebObjects then I will definitely give it a serious try for the reasons mentioned above.
I've been reading the entire articles and everybody talked about Webcomponent.
Could anyone tell me why one will jump to Tapestry instead of Expresso since it provides deeper Framework to build J2EE application?
Expresso goes beyond the Weblayer. And why it is worth to spend my time learning tapestry instead of learning Expresso which combines those web and app layer?
Expresson is a vertical framework, built on servlets and (of late) Struts for creating specific types of applications.
Tapestry is a horizontal framework for creating any type of web application. Because it is component oriented, it is designed (from the start) for extension and integration. This means that vertical frameworks, built on Tapestry, are very easy.
I don't doubt that, when someone needs it, a Tapestry framework will be created that accesses Expresso's back end.
Woo~~ . Thanks for these thoughtful posts
Firstly I should declare---- my English is really poor. I am a Chinese primary programmer workinging in Shanghai. So English is not my native language.:) I hope you guys can understand what I said.
Howard is right ,There's no point in attempting a discussion if your end of it is "I don't like it even though I haven't even looked at it." I haven’t any experience in developing web apps with Tapestry. So I think have not right to estimate it.
Last 6 month I spend a lot of time in designing and coding a MVC framework for my company. We called this framework as “Actionbase”. It’s really like “Structs”.
At the same time,some of my colleagues using this framework to do some large workflow driven web applications. At first,it seems worked good. Compared with model1,this one is better, easier to maintenance. The web flow is somewhat clear. So our framework also contain a switchable module for page authorization.
But it met some problems then. Integration is difficult(become large the definetion in xml is mess,some duplicated define in same naming space.). Actions are not reusable(although I know reusable is easy said than done.),.something just like these..
Next week I will try to do a prototype with Tapestry and compare it to my actionbase prototype. Try to dig into Tapestry and then give my suggestion here:)
P.S:what about talk about "Tapestry vs OfBiz" here???
Have a look at http://www.wings.to.com
. it's a mature servlet framework, using the models end event mechanism of swing and featuring complex components like: STree, STable, SMenu, SInternalFrame, LayoutManagers. Write your model once and use it with Swing and wingS.
Another important feature is the TemplateLayout, a Layoutmanager that places components in a standard html page. Just let the web agency care about html code and concentrate on coding the logic.
Even the plaf concept of Swing has been adopted in wingS: you can provide plafs for different browsers. A wap plaf is in development, already.
BTW: wingS is also released under the LGPL.
In case anyone is interested. Here is a viewlet that shows a very early version of Spindle, the Eclipse plugin for Tapestry. Really early, there is much more functionality now than is shown.
Also, it won't make much sense unless you are currently looking a Tapestry.
Be forwarned that you need a java-enabled browser and max out your screen resolution as the movie is huge!
Geoff - Spindle developer
Has anyone compared Tapestry with the Echo framework (http://www.nextapp.com/products/echo
I'm looking for a good framework and the Echo looks interesting. But then again so looks Tapertry.
I've only taken a very brief look at these other tools.
They are very clever; they take a Swing or Swing-like model to create web applications. Instead of using templates, you create classes in a Swing-like manner.
The model is familiar (if you are a Swing coder) ... but they perform all the layout work for you, using nested tables.
The WingZ author has claimed that you can regain control over layout.
These are a very (Java-)developer-centric view of web development.
Tapestry is organized around total freedom for the graphic designer and HTML producer.
There's also some scalability questions (i.e., clustering/fail-over support). Tapestry attempts to be a "good citizen" in its containing application server's clustering mechanism; it stores only a single object into the HttpSession and it tries to keep that object pretty small ... on the order of hundreds of bytes (though the more stateful an application, the larger this object gets).
Tapestry pages can be quite large and complex, the root of a tree of hundreds of objects. For this reason, Tapestry seperates page instances from page state, and uses a pooling mechanism for the page instances. Pages are extracted from the pool and have the appropriate state applied to them.
If Tapestry had to serialize the entire page just to store its state, the amount of data stored in the HttpSession would skyrocket.
Perhaps the authors of the other frameworks can jump in with their approaches to clustering/fail-over support?
In the case of JPublish I leave it up to the enclosing container to deal with clustering and/or failover. JPublish doesn't maintain state anywhere. Developers can place objects in the session or the application context if they choose, but JPublish itself does not place any objects in those spaces at this time.
JPublish does maintain caches for certain resources which are reused, as does Velocity (which JPublish uses as its template engine). I am considering using JCS
in a future release of JPublish so that cached objects can be resused across different servers. Perhaps you might want to take a look at that as a way of enhancing Tapestry's caching.
provides creation wizards, application and component editors and an Tapestry aware HTML editor.