TSS Book Review: Tapestry In Action

Discussions

News: TSS Book Review: Tapestry In Action

  1. TSS Book Review: Tapestry In Action (46 messages)

    Kris Thompson reviews Howard Lewis Ship's Tapestry In Action (Manning). The book reaches many different audiences: the beginning is dedicated to the developer just flirting with Tapestry, the middle chapters strongly geared to the Tapestry Power user, and the final chapters to the Architect. For those thinking about working with Tapestry, this book serves as an excellent guide.

    Read A Review of Tapestry In Action

    Threaded Messages (46)

  2. Another more accurate review[ Go to top ]

    http://www.javaranch.com/bunkhouse/J2EE.jsp#1932394117
  3. Another more accurate review[ Go to top ]

    What makes you think this other article is more accurate? I found the tone of the JavaRanch review to be nasty, not critical. I think Kris's review is much more accurate .... the information I packed into the book is the information I see almost every day on the Tapestry user mailing lists.
  4. What a Load of Crap[ Go to top ]

    I have 25 years of programming experience, including working for Microsoft and Sun on Java technologies, and I've used virtually every framework and templating engine out there over the past 7 years. All of them have some fatal defect, except Tapestry. IMO, Tapestry is by far the best framework available today. And this book is the way to learn it.

    Having read the first 4 chapters in one sitting, what I hear from this negative review is mostly a bunch of bitching about how the author didn't do the reviewer's homework. Yes, the examples are contrived. But they are contribed to demonstrate and develop points and to provide full coverage to all the areas of the framework (or at least what's possible in 400 pages).

    I'm amazed at both how wonderful Tapestry is (even when set next to my old favorites like Velocity/Freemarker/Tea/etc... and BTW, JSP was never worth discussing even back in the 1997/8 timeframe when it emerged) and how well this book explains it. If you want a cut-and-paste book that's 1100 pages long, you'll probably want to look somewhere else. If you want something fairly concise that actually explains to the thinking developer how Tapestry works, then this is just the ticket for you.
  5. Web Frameworks[ Go to top ]

    Hi, everyone found very usefull all this discussion. I am new on Java Web Frameworks and would like to conclude my thoughts on which one is good to learn. Open source™ the biggest movement and avaliability of all most every middleware/servers for few (with its vitue) are the things that makes everyone make a thought on his career. And finally I make my move. Choose Java™. Long list of persistance frameworks but confusing. Which one of you recommanded and where? Thanks
  6. So is this book about Tapestry 3?
  7. Tapestry version[ Go to top ]

    Yes, it's extremely up-to date. Some features of Tapestry 3.0 were developed in parallel with the book, and (unfortunately) Tapestry 3.0 was probably delayed several months while I was distracted working on the book. 3.0 is very close to a final release (the second release candidate was released today).
  8. Good book - congrates[ Go to top ]

    I would like to thank Howard for his work on Tapestry and the book. It is too easy to underestimate the work involved. Thanks is even more deserving when the financial rewards are minimal. I am very supportive of the Library and very pleased that the book is available as a resource. Its a polished well written text. Thanks to Howard and the Tapestry community. Your all a very talented group of people indeed.
  9. I think Howard did a fantastic job in putting down a lot of detail, which makes this book a very valuable source of information about the framework and how to use it.

    Fire up Eclipse, plug in Spindle, get the Book, and a beverage and start coding.
  10. I have just spend the last several days blazing through Tapestry (as a total newbie) with Tapestry in Action in hand (well, actually I have the eBook). It has been a very pleasant experience. I feel like Neo in the Matrix, I have all these new superpowers to create very rich Web UI features with much less effort. Everyone knows it, Tapestry rocks (I know Kung Fu)! If you want proof, spend several days checking it out. It's very powerful but works with totally different abstractions than Struts so it's not "easy" to learn. Though once you get through the paradigm shift, it's all really quite amazing and becomes incredibly "easy". I can't thank Howard and co. enough. What an enjoyable coding experience.

    At any rate, the book is not a reference book. It primarily is a series of tutorials (apart from, as the reviewer describes, the first chapters). Which is great because it shows a lot of code examples. The JavaRanch review cited above states that the Hangman example doesn't cut it (which in terms of Web UI is already more complex than say, pet store). Well, I have a feeling that reviewer didn't actually read the book or at least didn't get to the chapters where more complex but common issues are discussed (protected pages, complex HTML forms, etc.). The book continues to be a tremendous help and very successful aid. For reference materials, I find the Component Reference and the DTD specifications at the end of the Developer Guide (found on the project website) to be very useful.

    Brian J Farrar
  11. Thanks! A lot of people have worked very hard on Tapestry and Geoff particularily has done an incredible job with Spindle.

    One of the critcisms that sticks is the title of the book. "Tapestry in Action" was sort of the title by default, but I can see how it does not fit so well with the other "In Action" books. Many of the others (XDoclet, Jess, AspectJ, etc.) fit the mold better: they are complex systems made up of a number of discrete sub-systems, so its easier to be very task-oriented in describing them.

    Tapestry consists of a number of intertwined concepts and subsystems, which is part of the supposed "steep learning curve". You really need to understand, at a shallow level, quite a bit to fully understand what Tapestry is doing for you. In this respect, the book is a "Guided Tour" of Tapestry, leading you along from one concept to the next in what I think is the best order to really understand what Tapestry does, without getting overwhelmed by the details.

    BTW, the User's Guide has the most up-to date details about the latest DTDs (as does the book).
  12. TSS Book Review: Tapestry In Action[ Go to top ]

    I must confess I don't know Tapestry. It seems to ease web GUI development. Thats what I believe to know about it.

    If this is the only thing, then I think there are better approaches for GUI development, like Abstract User Interface Markup Language Toolkit: http://www.alphaworks.ibm.com/tech/auiml?open&S_PKG=&S_TACT=104AHW61&S_CMP=GR&ca=dgr-awjw22auiml

    This is a commercial product, but I really would like that something like this would be open source and becomes mainstream for writing GUIs. Imagine writing a GUI in a markup language which can be automatically converted into Swing, HTML or even SWT or Shockwave!

    I think we should put more community effort into this technologies instead of putting it into web or Swing frameworks.
  13. Imagine writing a GUI in a markup language which can be automatically converted into Swing, HTML or even SWT or Shockwave!
    While this sounds extremely good on paper, one has to take into account that the request-response paradigm (epitomized by web apps) is _fundamentally_ rather different than the client-side stuff that is usually done using Swing, etc. There are a lot of things that are an absolute need in one, but make no sense at all in the other. This is especially true of the way data is handled by the application.

    In general, trying to combine the two into one is exactly like driving a square peg in a round hole. You could combine them, but that means that you either (a) limit yourself to the lowest common denominator and do not use the full features of each platform, or (b) are not doing something right.

    The reason Tapestry is so helpful to many people is because it is focused at one paradigm and does that very well -- web applications. It does not try to be everything to everyone (even though it does have the fundamentals to do that) and it does not have to limit itself as a result.

    One can argue what the best paradigm to write apps in is. But if you are targeting the browser via web applications for practical or other reasons, then Tapestry is an excellent weapon of choice.
  14. We cannot know if this works if we don't try to do it.

    Your objection may mean that 20% are different. So 80% would be common between Swing and HTML markup.

    Look at Casabac: http://www.casabac.de/

    It looks like a rich client, but is only a web client. Its so similiar to Swing. Only very few things are not common, maybe 10%. There could be a automatical default behaviour if the 10% are not specified for a client type.

    Nothing is impossible. And a lot of things are really easy when it is discovered how to do it.
  15. Have you looked at WebCream?[ Go to top ]

    We cannot know if this works if we don't try to do it.Your objection may mean that 20% are different. So 80% would be common between Swing and HTML markup.Look at Casabac: http://www.casabac.de/It looks like a rich client, but is only a web client. Its so similiar to Swing. Only very few things are not common, maybe 10%. There could be a automatical default behaviour if the 10% are not specified for a client type.Nothing is impossible. And a lot of things are really easy when it is discovered how to do it.
    Looks pretty cool although performs very slowly on my machine. I didn't have time to investigate fully, but is there a GUI editor for the UIs? As I understand they are all custom and a programmer would have to learn the APIs. Is that true?

    Have you guys looked at WebCream (http://www.creamtec.com/webcream/)? It is pretty much the same thing but it web-enables Swing so the developers either do nothing (if they already have a Swing UI) or design the Swing using whatever standard tools they like.
  16. if you're into it, theres more options to look at. Heres one that also mirrors the swing API, and is free incl. source:

    http://www.swinglets.com/downloads.jsp?download=swinglets

    If you're looking for strong tool support, theres W4T from http://w4toolkit.de, which seems to be a proprietary API.

    Other component-oriented frameworks that come to my mind are echo and millstone, both open source (sf.net) and well-supported.

    IMO Tapestry stands out in that it provides a very good combination of object-orientation , reusable components, templates, tool support and a strong community. However, depending on the task at hand, others may do a better job.

    Christian
  17. Is there a GUI editor
    Yes there is one as part of the toolset: The layout of a page is kept in an XML file, the editor offers comfortable editing of this file and the possibility to WYSIWYG preview the result. From the WYSIWYG preview you can navigate into the XML hierarchy etc. Since 3.0 (just in release phase) it also offers wizards for the controls. BTW: the editor "of course" also runs inside the browser...

    >> Controls, "...they are all custom...":
    There is a standard control library coming with the product covering a really rich set of controls (incl. menus, trees, grids. All you see in our demo is contained.) In addition you can create own controls.
    The development process is: you create your page by arranging controls and you write a logical counter part of the page as Java class (e.g. a CHECKBOX control is represented by a boolean-property). You do not see "HTML" or "Javascript". I.e. you just have to take care of the server side aspect.

    >> Performance
    Performance of demo area: this is a small demo machine located in Germany - please use our donwload area, download the product and run the server in your own environment. We expect the browser's hardware to be 500 Mhz minimum.

    Bjoern Mueller, Casabac Technologies, http://www.casabac.com
  18. TSS Book Review: Tapestry In Action[ Go to top ]

    Kris has done a fair review IMO.

    I've read many drafts of "Tapestry in Action" while reviewing it for the publisher over the last year or so. As a long time Tapestry user I found that Howard has done a lot to please both camps, new users and current users that is.

    This could have been another "buy it, scan it, plop it on the bookshelf to gather dust" kinda book. These are quite common unfortunately. "Tapestry in Action" does not fall into this category (regardless of what that guy at the ranch says - did he even read it, or try Tapestry?).

    Things that caught my eye were good illustration of the things that catch up newbies an occasionally veterens alike:

    - Best Practices
    - Things to Avoid
    - Important to Know
    - Problems frequently encountered by Newbies

    I wanted to put in page/para references for the above, but Manning has not yet seen fit to send me a physical copy. argh.

    Although, I did manage to find an example in the online chapter 2:

    Section 2.2.1 - Warning - Use the correct <!DOCTYPE>.
    A common thing that trips up newbies. Plus the warning goes on to explain it in great detail.

    I think that this book is not only a great introduction to Tapestry, but will remain a great reference for developers even as they delve into writing applications and become proficient.

    Geoff
  19. TSS Book Review: Tapestry In Action[ Go to top ]

    Can somebody tell me if Tapestry and JavaServerFaces achieve exactly the same thing? If not, what are the differences, which is better?
  20. Tapestry - competitor to JSF[ Go to top ]

    I'm not a Tapestry user, although I was intrested in this project for very long time. (I'm using Spring now)
    I could be wrong, but from what I see - Tapestry is in direct competition with JSF.
    Is there any ideas - what this competition will bring us ? Will it kill Tapestry ? (it surely cannot kill JSF since JSF is a *standart* now.)
  21. Tapestry and JSF[ Go to top ]

    Can somebody tell me if Tapestry and JavaServerFaces achieve exactly the same thing? If not, what are the differences, which is better?
    Tapestry is the Hibernate of web tier technologies. JSF is the Entity EJB.
  22. TSS Book Review: Tapestry In Action[ Go to top ]

    Can somebody tell me if Tapestry and JavaServerFaces achieve exactly the same thing? If not, what are the differences, which is better?
    Both Tapestry and JSF are component technologies in theory. Exactly as OO languages for the web, they should allow you place in "black boxes" the common functionaly that is quite prevalent in web applications. This allows you to both use that functionality in different places easily in the future (something particularly important for better teamwork) and to avoid using the same code over and over using the copy-paste approach.

    In practice, unfortunately, the situation is rather different. While components in Tapestry are easy to make and are very similar to pages (in fact, pages are just a special type of components, nothing more), in JSF components require a lot of extra work, are extremely different beasts than the rest of the code, and finally they are rather limited as well. I will detail this claim further down, but before that consider the practical impact.

    In our work we have created and are using _hundreds_ of Tapestry components from rather small things like a color chooser, to complex beasts for generic management of lists of objects or for handling of fully dynamic forms. Most reused stuff is a component for us. I use those freely left, right, and center, even though they have been written by other people (coleagues of mine) and I have absolutely no idea how exactly they work. The complexity and limitations of JSF on the other hand mean that we would have created only 20-30 of those components _at most_. The rest would either be impossible (okay, very hard to do), or the marginal benefit of making them would be rather low. The resulting repetition of code and related problems would be staggering.

    So what are those limitations? For starters, JSF is using Tags to define its components and that automatically leads to several problems:

    - parameters can only be strings. In Tapestry they can be of any Java type -- String, int, ArrayList, etc.

    - parameters are read-only, i.e. the component cannot "return" values through its interface. In Tapestry parameters are read-write, something that is particularly useful for form components when a value is entered by the user, for example.

    - in JSF components write the HTML similar to servlets -- using Java code. In Tapestry the components use an HTML template just like pages.

    - Finally, this is most critical and most limiting: a JSF component cannot easily use other JSF components in its implementation. That essentially means there is an upper limit to the complexity that can be abstracted in JSF components. In Tapestry, on the other hand, it is the natural for a component to use other components to implement its behaviour. In our case, for example, the resulting tree often reaches depths of 6-7 and a single component can be responsible for doing much more as a result.

    One other thing: the procedure for creating a JSF component is rather elaborate. The tutorial lists 9 steps (plus 6 sub-steps) one has to follow to do that in the general case. Even with a tool, that will be a bit of a headache. In contrast, creating a component in Tapestry is much more trivial and is natural for pretty much every developer on the team -- one is essentially encouraged not only to use components, but also to create them. In general, I have no doubt that in the next months a number of add-on frameworks will appear that correct those issues in the JSF. Unfortunately, some of them are simply fundamental and unfixable.

    I hope this response is informative and helpful. In any case, I would recommend that one has a look at the free chapters of the book (http://www.manning.com/catalog/view.php?book=lewisship&item=chapters) and see whether what is shown there looks intriguing.
  23. JXTA & Web service[ Go to top ]

    My aplogoy for the far off-the-topic question,
    Does JXTA complement Web Service, or does it offer and an alternative to the whole Web Service shabang ? .

    thank u
    Faisal
  24. Can not agree more[ Go to top ]

    I believe Tapestry will beat JSF in component architecture.
  25. Careful with that prediction[ Go to top ]

    There's still a lot of unknowns regarding JSF. Based on what little I've read of Tapestry and JSF and the intended use and audience, I think they will coexist in slightly different markets. From what I understand JSF is targeted at tool builders (IDEs) for VB-like RAD of small applications. Tapesty seems more of an all-around tool for various project sizes or for specialized UI applications.

    Anyway, because JSF is blessed by the JCP and Sun I expect a fair amount of support over the next year or so. If it turns out to be bad, it will die a slow death. But if it's good at what it's intended, it will be around for some time to come.

    The biggest unknown is how many of and how well the tool/IDE vendors will support JSF (like Javs Studio Creator, yet to be released) and how many freely available 'components' will show up. Component EJBs never really happened, but EJBs are still being used. After a couple years many many articles were written suggesting they are overused and overcomplicated, but there's still valid reasons to use them in certain situations. JSF may end up like that, or it may not. The entry is different in that EJBs didn't really have competitors (except maybe CORBA?), but JSF does. The success and/or survival of JSF is speculation at this point, so we'll wait and see...
  26. The biggest unknown is how many of and how well the tool/IDE vendors will support JSF (like Javs Studio Creator, yet to be released) and how many freely available 'components' will show up.
    IBM is supporting JSF with Websphere Studio Application Developer

    WSAD 5.1.1 includes JSF tools.

    http://www-106.ibm.com/developerworks/websphere/techjournal/0403_barcia/0403_barcia.html
  27. Didn't know about that![ Go to top ]

    Didn't know anything outside of the JSF Console existed yet for JSF. It looks a lot like I thought it might. But I'm not quite so sure about Barcia's notion of it being quick and efficient. I admit some of the stuff in the article is artificial setup, and there's a lot of screenshots that make it tough to tell just how many clicks and entry fields you have to make, but to me it just seemed more like a GUI way of doing what takes about the same amount of time with a regular text editor. ie, different, not necessarily faster.

    It does integrate a lot of things, though, so all the resources are right there in the IDE and can be selected using the GUI. I guess I won't be able to tell until I can do a hands-on test. Is there a "community" edition of WSAD that supports deployment to or includes Tomcat?

    Thanks for the info!
  28. Re: JSF tools[ Go to top ]

    Gerry,

    FYI, several other tools for JSF are in the works (including ones from Borland, Oracle, and Exadel). You can find a full list at JSF Central.

    Kito D. Mann
    Author, JSF in Action
    http://www.JSFCentral.com - JSF FAQ, news, and info

    > Didn't know anything outside of the JSF Console existed yet for JSF. It looks > a lot like I thought it might. But I'm not quite so sure about Barcia's
    > notion of it being quick and efficient. I admit some of the stuff in the
    > article is artificial setup, and there's a lot of screenshots that make it
    > tough to tell just how many clicks and entry fields you have to make, but to
    > me it just seemed more like a GUI way of doing what takes about the same
    > amount of time with a regular text editor. ie, different, not necessarily
    > faster.

    > It does integrate a lot of things, though, so all the resources are right
    > there in the IDE and can be selected using the GUI. I guess I won't be able
    > to tell until I can do a hands-on test. Is there a "community" edition of
    > WSAD that supports deployment to or includes Tomcat?
  29. TSS Book Review: Tapestry In Action[ Go to top ]

    I can second Mind Bridge's comments -- we've used Tapestry in a large project and found:

    * overhead to create a component is low
    * parameterising them to allow reuse in different situations is easy
    * composing them into more complicated components is simple.

    This allows us to have each part of our UI in 'one place', so changes and maintenance are easy.

    Tom
  30. TSS Book Review: Tapestry In Action[ Go to top ]

    Other than JSF being a standard, is there anything about JSF that can be considered superior to Tapestry. Can JSF do anything that Tapestry cant.
  31. TSS Book Review: Tapestry In Action[ Go to top ]

    Can JSF do anything that Tapestry cant.
    Hmm... convincing Project Managers as always win - *standart* solution ?
  32. Tapestry vs JSF[ Go to top ]

    Hmm... convincing Project Managers as always win - *standart* solution ?

    Well, I'm a total Tapestry newbie. I've been working with Tapestry for roughly the last two weeks, within that time I've:

    - Got the book and studied the framework and played around with Spindle (two days)
    - implemented a Tapestry component similar to StrutsMenu (took me three days, if I had know what I know now, I could do it in less than one)
    - implemented a User Administration web interface, CRUD User, some reports, Login (Four days, of course, I'm also using Spring and Hibernate)

    Try to get that velocity with JSF. Try to build a component library with JSF. Try to get all the flexible yet easy to implement HTML form handling (including the error stuff) going with JSF. Not going to happen.

    Why do you think "standart" solutions always win (just like EJB Entities right??)? The right question is why do "standart" solutions always lose (just to be replaced by another loser "standart" solution)? You may want to rethink how competitive your Project ROI really is by using the "standart" solutions.

    Honestly, this what I ask myself: How much time and money has been wasted on the projects I've worked on using Struts and XSLT over the past two years? I could have been using Tapestry and saved so much work! Line precise error reporting has probably already saved me two days of work. Everytime I get a Tapestry error message I learn an incredible amount about how to use the framework. Everything about Tapestry is focused on true developer productivity.

    Tapestry rocks, plain and simple. If you think otherwise, you haven't tried it. Much like Hibernate, it is that hard-to-come-by framework that makes everything really easy but, at the same time, doesn't hinder your creativity or shut off the ability to deal with abnormal requirements (which as we all know are rather normal).

    Can JSF do anything that Taestry can't?
    Yes, JSF can actually make your life more difficult than it already is.
  33. Tapestry vs JSF[ Go to top ]

    >>>>Hmm... convincing Project Managers as always win - *standart* solution ? Well, I'm a total Tapestry newbie. I've been working with Tapestry for roughly the last two weeks, within that time I've:- Got the book and studied the framework and played around with Spindle (two days)- implemented a Tapestry component similar to StrutsMenu (took me three days, if I had know what I know now, I could do it in less than one)- implemented a User Administration web interface, CRUD User, some reports, Login (Four days, of course, I'm also using Spring and Hibernate)Try to get that velocity with JSF.
    So you are actually comparing a 3 year old finished PRODUCT with an brand new standard? Or maybe even an RI, which is nothing but a proof of concept, far from a production ready product? C'mon people, JSF is not a tool, JSF is not a product, what you are all comparing to is just a simple proof that the specification is viable, a Reference Implementation. Come back later when tools and IDEs for JSF are ready. Then you will be able to compare both at the same level. Right now you are comparing a real car with a simple and bare prototype.
    Try to build a component library with JSF. Try to get all the flexible yet easy to implement HTML form handling (including the error stuff) going with JSF. Not going to happen.
    I beg to differ. It may not be that easy right now, but that's because we are using a bare-bones RI of JSF, it is not meant to be used that way, soon you will be able to develop JSF web applications using drag and drop tools, you won't have to code most of it by hand if you don't need or want to.
    Why do you think "standart" solutions always win (just like EJB Entities right??)? The right question is why do "standart" solutions always lose (just to be replaced by another loser "standart" solution)?
    Yeah, JDBC always loose...
    You may want to rethink how competitive your Project ROI really is by using the "standart" solutions.Honestly, this what I ask myself: How much time and money has been wasted on the projects I've worked on using Struts and XSLT over the past two years?
    And what is standard about Struts? Struts is not a standard, so this "standards always loose" logic is false, as you are complaining about it.
    I could have been using Tapestry and saved so much work! Line precise error reporting has probably already saved me two days of work. Everytime I get a Tapestry error message I learn an incredible amount about how to use the framework. Everything about Tapestry is focused on true developer productivity. Tapestry rocks, plain and simple. If you think otherwise, you haven't tried it. Much like Hibernate, it is that hard-to-come-by framework that makes everything really easy but, at the same time, doesn't hinder your creativity or shut off the ability to deal with abnormal requirements (which as we all know are rather normal). Can JSF do anything that Taestry can't? Yes, JSF can actually make your life more difficult than it already is.
    Like I said, JSF as it stands now is like TCP/IP back in arpanet time, I wouldn't drop my SNA network for that too back then... ;)

    Just wait for real tools, IDEs and components built on and compliant to JSF to come by before dropping it. Yes, it can do what Tapestry does, and much more. But not the RI. JSF right now is just a standard, not a product, so it is up to the market and community to develop upon it and deliver the JSF based products and tools that we need, but this is just not going to happen from night to day.

    PS: I am not saying that tapestry doesn't rock, it does. But to compare it to JSF as it stands right now is unfair and misleading.

    PS2: I needed an hierarquical tree component for tapestry for a project of mine but couldn't find it, can someone point the direction to me? If it doesn't exist, either I'll have to build one myself, or JSF already has something that tapestry doesn't... ;)

    Regards,
    Henrique Steckelberg
  34. Tapestry vs JSF[ Go to top ]

    So you are actually comparing a 3 year old finished PRODUCT with an brand new standard? Or maybe even an RI, which is nothing but a proof of concept, far from a production ready product?
    Well... I guess you answer the question of what the difference is :)

    I think one of the problems that people have with JSF is that they have heard the words "Just wait" way too often (you use them as well). It does get old after a couple of years, I think. During that period one could have used something else, and when things are finally ready, they and other similar product(s) will be well ahead again. Not to mention that a 1.0 revision _always_ misses things that are important in real life.
    Yes, it can do what Tapestry does, and much more.
    Unfortunately, it cannot do what Tapestry does. See my previous message for details -- the limitations are spectacular and their cost in practice is significant. Some things simply _cannot_ be fixed by tools. If they are fixed, then the tools will no longer be JCP compliant, which is the theoretical advantage of JSF.

    I love standards in general. They help a lot. But bad standards pull development back, not forward, and very unfortunately JSF is one of them, as it can be seen above.
    PS2: I needed an hierarquical tree component for tapestry for a project of mine but couldn't find it, can someone point the direction to me? If it doesn't exist, either I'll have to build one myself, or JSF already has something that tapestry doesn't... ;)
    It is in the standard distribution, together with 84 other standard components.
  35. Tapestry vs JSF[ Go to top ]

    Well... I guess you answer the question of what the difference is :)I think one of the problems that people have with JSF is that they have heard the words "Just wait" way too often (you use them as well). It does get old after a couple of years, I think. During that period one could have used something else, and when things are finally ready, they and other similar product(s) will be well ahead again. Not to mention that a 1.0 revision _always_ misses things that are important in real life.
    Well, by this logic we would still be riding steam trains nowadays. Do you think Diesel Locos didn't have any problems in the begining? ;) I think the problem is that people's expectations were too high, most of us were expecting the holy grail, the one-click solution to web development, and when something simpler and "unfinished" came out, they were disappointed. It doesn't mean it is uncomplete, it means it is up to market and comunity to implement it to its full potential, being it a specification... but the potential is already there.
    Unfortunately, it cannot do what Tapestry does. See my previous message for details -- the limitations are spectacular and their cost in practice is significant. Some things simply _cannot_ be fixed by tools. If they are fixed, then the tools will no longer be JCP compliant, which is the theoretical advantage of JSF.I love standards in general. They help a lot. But bad standards pull development back, not forward, and very unfortunately JSF is one of them, as it can be seen above.
    Well, I actually didn't get exactly what you meant in each JSF limitation you stated, but maybe it's just my somewhat limited knowledge of tapestry and JSF. But as I understood it, they are just limitations compared to tapestry, and not major failures that impede JSF adoption. Of course each framework has its strengths, easy component creation being one of them for tapestry. JSF has other strengths, like pluggable rendering, multiple implementations, allowing for lower lock-in and greater reuse, both of source code, components and knowledge between different implementations and projects.
    It is in the standard distribution, together with 84 other standard components.


    Ok, I'd like to use them to generate an SVG interface or HTML (depending on the client configuration), and in a vendor's suported implementation and specific visual IDE tool, and if this vendor goes out of business, switch to another implementation too or even to an open source one, will I be able to? ;)

    See, JSF is not here to be the end of all web frameworks, it is here to allow for greater souce code and knowledge reuse and help lower lock-in, through standardization. It is not meant to be the perfect tool or product, to compete, but to help. Whether it will accomplish that, only time will tell.

    Regards,
    Henrique Steckelberg
  36. Tapestry Tree Component[ Go to top ]

    PS2: I needed an hierarquical tree component for tapestry for a project of mine but couldn't find it, can someone point the direction to me? If it doesn't exist, either I'll have to build one myself, or JSF already has something that tapestry doesn't... ;)Regards,Henrique Steckelberg
    http://jakarta.apache.org/tapestry/doc/api/org/apache/tapestry/contrib/tree/components/Tree.html

    This should be documented in the component reference, but currently is missing. It was recently added to the Tapestry contriib library from the Tacos Sourceforge project. The Tapestry demo Workbench application has two examples of it in use.
  37. Tapestry vs JSF[ Go to top ]

    I am not saying that tapestry doesn't rock, it does. But to compare it to JSF as it stands right now is unfair and misleading.
    Yes, it is very misleading to compare a real, working, open-source product with several years of refinement (based on actual end-user feedback) to the shifting vaporware that is JSF. Please get back to us in a couple of years when there are real, useable implementations ... then we can discuss the underlying issue: developer productivity.

    I keep hearing promises, promises, promises about JSF but so far, nothing real. A lot of the real challenges that JSF will hit when they try to create truly complex components are issues I hit in Tapestry 2 - 3 years ago. I had the flexibility to change my design, but JCP inertia makes that pretty unlikely.

    Now, would it be possible to discuss Tapestry and Tapestry In Action? If you feel this discussion is so worthwhile, please start a Tapestry vs. JSF news item, but it is pretty rude to co-opt a discussion for your own ends (and yes, I know I did so in the past ... and stopped when it was pointed it out to me).
  38. TSS needs a retract button. As annoying as this Tapestry vs. JSF discussion is, it is not Mr. Steckleberg's responsibility and I apologize for being so rude myself as to accuse him. But I would like more discussion about Tapestry and the book!
  39. TSS needs a retract button. As annoying as this Tapestry vs. JSF discussion is, it is not Mr. Steckleberg's responsibility and I apologize for being so rude myself as to accuse him. But I would like more discussion about Tapestry and the book!
    I am sorry if I have "hijacked" the thread to off topic realms, but I felt that since both are "web frameworks", and had JSF been brought to the discussion by other forum members, I though I could add something to the discussion. This could be regarded as not so off-topic for some, but either way I apologise. I am a great fan of Tapestry myself, but lately have felt that some kind of standard should appear, because of the great number of web frameworks out there, with new ones poping up everyday. Any standard, even a not perfect one, could help us in this, instead of having 100s of different solutions for the same problem. We can take JSF as a "new kid in the block", or we can embrace it as a ways of having common knowledge from where specific frameworks develop upon, leveraging on a common and stable ground which allows reuse and flexibility.

    ops, there I was going again...end of discussion! sorry for that. ;)

    Henrique Steckelberg
  40. Tapestry vs JSF: an apology[ Go to top ]

    Howard, I am sorry u feel this way. I dont think that Tapestry VS JSF discussion on this thread is that bad after all. Maybe it is slightly off topic, but it is really useful. I have neither used Tapestry nor JSF, and I am at a point where i am about to begin using one. And from the outcome of this thread, I am leaning towards Tapestry and also planning to buy ur book. U cud always argue that this cud be part of some other thread, but when u have both Tapestry and JSF experts here, i think this wud be the best place to get such comparison feedback.
  41. TSS Book Review: Tapestry In Action[ Go to top ]

    Other than JSF being a standard, is there anything about JSF that can be considered superior to Tapestry. Can JSF do anything that Tapestry cant.

    It has better support for existing standards (taglibs for example, which Tapestry doesn't have), and for that reason alone it'll do very well.

    But maybe the real question is how fast you can accomplish what you want to do, and how elegantly you can do it.

    I had a crack at doing a website in Tapestry a few weeks ago. Nothing major. About eight 'pages' talking to a Hibernate layer to a MySQL backend.

    From reading the tutorial to actually having a website up and going was about an hour. Not because I'm ridiculously clever, but because the whole thing just makes sense. You look at it, and you think 'so that's what all the fuss is about.'

    JSF will have tools? Maybe, but Tapestry has tools already. I used Dreamweaver for the site design, and because Tapestry doesn't stick tags or weird bits of markup on the page, what I designed was what I got. That alone was worth the time spent on the tutorials. Now I shudder to think of the hours I spend tweaking HTML template code because they render differently because of the tags.

    Did I make mistakes? I certainly did, but Tapestry told me exactly where the mistake was, and what I had done wrong. A framework that teaches you while you use it? What a bizarre idea!

    Rather than writing loads of Java code to handle requests, responses and sessions and whatnot, you just write code to do stuff. Tapestry takes care of all that plumbing stuff for you. In fact, you don't so much as write code, you just knit objects together in XML and present them to your template.

    Having said that though; I can see where Sun is coming from with JSF; they want to move forward, but they know that developers will not abandon existing codebases to move with them. I can imagine the uproar if Sun said they were abandoning taglibs. So by the looks of it, JSF is something of a halfway house. It lacks the elegance of Tapestry, but the support for existing technology, and support by third parties will make it a success.
  42. Re: JSF limitations[ Go to top ]

    I just wanted to correct a few misconceptions about JSF:

    - For starters, JSF is using Tags to define its components and that automatically leads to several problems

    By default, it uses JSP tags, but that's by no means a requirement.

    - parameters can only be strings. In Tapestry they can be of any Java type -- String, int, ArrayList, etc.

    Parameters for JSF components can be any object type as well -- you can use JSF expressions for any parameter. The tag libraries accept attributes as strings so that they can use expressions.

    - parameters are read-only, i.e. the component cannot "return" values through its interface. In Tapestry parameters are read-write, something that is particularly useful for form components when a value is entered by the user, for example.

    Component values in JSF are read/write -- JSF can automatically synchronize the component's value (collected from the user) with a property of any object in your application, performing conversions along the way.

    - in JSF components write the HTML similar to servlets -- using Java code. In Tapestry the components use an HTML template just like pages.

    Agreed -- this is annoying. There's nothing that stops someone from adding support for a templating language, however. I think Exadel may be using Velocity for this.

    - Finally, this is most critical and most limiting: a JSF component cannot easily use other JSF components in its implementation. That essentially means there is an upper limit to the complexity that can be abstracted in JSF components. In Tapestry, on the other hand, it is the natural for a component to use other components to implement its behaviour. In our case, for example, the resulting tree often reaches depths of 6-7 and a single component can be responsible for doing much more as a result.

    I'm not sure what you're talking about here, since I've written several JSF components that are a composed of smaller ones -- composite components, if you will.

    - One other thing: the procedure for creating a JSF component is rather elaborate.

    I think most of the "elaborate" issues with JSF component development is integration with JSP, which requires a JSP custom tag. Other than that, at a minimum all you have to do is write a single class and register it in an XML file.

    Kito D. Mann
    Author, JSF in Action
    http://www.JSFCentral.com - JSF FAQ, news, and info
  43. I am not sure why Mr. Mann insists on promoting inferior technology, i.e. promote JSF. Evidently, you have not written a great deal of JSF, JSP or Struts code, or EJB to see the nasty unneeded complexity of the screwed up J2EE apis. You really need really need to write the same app in Tapestry and then write it in JSF; yes in that order. And then just let your brain make the decision for you.

    Mr. Mann and other people like you out there can help make Java Web Development a little it bit more exciting not more complicated.
  44. two thumbs up[ Go to top ]

    As a Tapestry newbie, I am grateful for the detaild explanations and code examples and find them very helpful. Howard has done a great job both with the book and the framework!
  45. Examples of Tapestry in production?[ Go to top ]

    I'm really excited by what I've seen of Tapestry, but I'm not quite at the point where I could recommend it's use on a production website yet. My main concern is scaleability and performance. The approach seems likely to be more processor intensive than most jsp based frameworks and also to encourage applications that carry a lot around in the http session. Maybe I'm being over cautious as a result of past experiences. I was on a large project using WebObjects that got severely burned by issues with performance, scaleability and generally intractable weirdness. It seemed like we'd hit a level of complexity at which the platform just started coming apart at the seams. (Mind you this was a long time ago and maybe WebObjects got better.) Every time I see someone mentions that Tapestry is similar to WebObjects I get a funny shivery feeling...

    Does any one have any experiences of Tapestry in large projects, high volume production sites etc?
  46. nhl.com, portions of smartprice.com

    This is a frequent request. I hope to have some examples I've personally worked on within a few months.

    WebObjects had a habit of keeping multiple copies of the same object around in memory. That's where the "obscene memory footprint" comes from.

    Tapestry has always seperated the persistent state of a page or component from any particular instance. This allows a small number of page instances to be pooled, then returned to the correct state for use by a particular user.

    What you see in the HttpSession is a smattering of attributes; each persistent property is stored into its own attribute (the attribute key incorporates the name of the application, the name of the page, the name of the component, and the name of the property). In addition, the engine (with the Visit object) is serialized into its own attribute.
  47. Examples of Tapestry in production?[ Go to top ]

    We don't have a system in production yet, but we have a complex system (about 100 pages, and about 100 components) with 300 to 600 component instantiations per page and a deepest nesting typically of 6.

    Our application is a 'web application' rather than a 'web site' -- that is, every page is very DB and business logic intensive.

    Tapestry is very scalable from a development point of view -- files don't become unmanagable, dependencies don't get out of control.

    We certainly see no weirdness -- Tapestry just works.

    It's always hard to give good performance figures, but we find that the bottleneck in our applications is *always* the DB, not Tapestry.

    That 600 component page takes less than 50ms to render on a fast P4 -- but a lot of that is going to the EJB server, getting the data from the DB, putting it into the value objects etc. From my last profiling exercise I'd guess Tapestry is taking less than 10ms.

    Tom