Why you should consider Tapestry 5

Discussions

News: Why you should consider Tapestry 5

  1. Why you should consider Tapestry 5 (101 messages)

    Tapestry 5.0.14 has been out recently and the Tapestry community is very excited with this news because Tapestry 5 is only one step away for being GA. In case you haven’t heard of T5, it’s an opensource component based web framework which is a total revamp from the previous version. Some people may not like the previous version because of the learning curve on using it. Some people even wrote rants about the previous version. But T5 is totally a different architecture with the same way of thinking as the previous version. So what’s so good about T5? And why should you consider it for your next project? Here’s my personal reason based on my experience building my opensource project using T5. Create custom components easily and quicker Think about creating custom components with Taglib, or even worse think about creating custom components with JSF. Forget about those scary days, now creating components with T5 is so much fun because basically it is just a plain POJO. Read the rest at http://joshuajava.wordpress.com/2008/08/21/why-you-should-consider-tapestry-5/

    Threaded Messages (101)

  2. "Because Tapestry 6 will be totally a different architecture with the same way of thinking as the previous version." m2c
  3. "Because the developers will make sweeping changes on a whim" http://www.bileblog.org/2007/09/the-tapestry-bearded-wonder/
  4. Yea but...[ Go to top ]

    "Because Tapestry 6 will be totally a different architecture with the same way of thinking as the previous version."

    m2c
    Maybe, and not that I'm saying that's a good thing per se, but at least you're not riding the sacred cow of backwards compatibility. Take WindowsXP for example...
  5. FUD and Trolls[ Go to top ]

    It's getting to the point where I'd almost rather TheServerSide didn't post anything about Tapestry, since the only active members are FUDsters and Trolls. Don't you guys have anything better to do? Well, for the benefit of the open minded ... Tapestry 5 has a rock solid, yet adaptable API. I've spent over two years working on Tapestry 5 and one of the central goals is to eliminate backwards compatibility problems for future releases, without handicapping the ability to make significant improvements. Tapestry 5 doesn't represent the kind of refinement that took place between Tapestry 3 and Tapestry 4 (which caused unfortunate backwards compatibility problems, largely due to the extensive use of inheritance for components) ... instead, Tapestry 5 rewinds Tapestry back to its initial, solid, time-proven core concepts and rolls out entirely new code. Along the way, we've improved every aspect of Tapestry. Live class reloading means you don't have to redeploy your application to see changes. Just recompile the Java code and hit refresh. Templates have been streamlined and simplified. Feedback, including the exception report page, has been improved. Components and pages are now POJOs: not abstract, no interfaces, no super-classes. No XML configuration. At all! (ok, one short entry in web.xml). Built in client- and server-side validation along with Ajax support (built on Prototype and Scriptaculous). We're gettng very close to a Release Candidate. And that's what I should be working on right now.
  6. Re: FUD and Trolls[ Go to top ]

    While the language is strong, is the concern unwarranted? Tap5 breaks Tap4 which broke Tap3. I did look at Tap3 back in the day and actually started that process of bringing the management on board. But when Tap4 came out, I held out, and to be frank, I was glad. It broke Tap 3. Was this a one time thing? You said Tap4 was a "from the ground up" change, right? "Includes better IOC than Spring(or Hivemind(which was better than Spring))", right? How would I have looked when the Tap5 beta came out stating that Tap4 apps weren't supported? What if I'd moved stuff to Hivemind, which is gone? You can have an open mind, but the track record(and one's job security) demands healthy skepticism, does it not?
  7. track record is scary[ Go to top ]

    even I was looking at TS5 but reading stories of earlier version simply no chance of touching it again.. I am not saying it is bad or good but stability or moving forward concept is not strong. I like Flex more compare to GWT and Appcelerator..
  8. Re: FUD and Trolls[ Go to top ]

    I know it was very scary back in the past during the T3 and T4 era. But I believe Howard has learned alot from the past and everything is different now. At first sight, there was sceptism from me about T5 too. But after trying it out, I'm just amused of how T5 solves common problems in web application development.
  9. Re: FUD and Trolls[ Go to top ]

    But I believe Howard has learned alot from the past and everything is different now.
    I believe this is precisely what many are afraid of.
  10. Re: FUD and Trolls[ Go to top ]

    Without change their is no innovation. I'm pretty sure T5 was the first web framework to be completely annotation driven (via a now very similar to guice IoC container) as well as support live class reloading of your web app as you work on it. I wouldn't be surprised if the amount of time you save not having to restart your gigantic web app all the time outweighed any time spent on dealing with changes. You're working in the wrong industry if you can't handle change. (unless you are happy to become one of those useless old dinosaur programmers that still desperately clings to hand written jdbc DAO code or other similar traits shared by dinosaur programmers ... =p )
    But I believe Howard has learned alot from the past and everything is different now.


    I believe this is precisely what many are afraid of.
  11. Re: FUD and Trolls[ Go to top ]

    Without change their is no innovation.

    I'm pretty sure T5 was the first web framework to be completely annotation driven (via a now very similar to guice IoC container) as well as support live class reloading of your web app as you work on it. I wouldn't be surprised if the amount of time you save not having to restart your gigantic web app all the time outweighed any time spent on dealing with changes.

    You're working in the wrong industry if you can't handle change. (unless you are happy to become one of those useless old dinosaur programmers that still desperately clings to hand written jdbc DAO code or other similar traits shared by dinosaur programmers ... =p )

    But I believe Howard has learned alot from the past and everything is different now.


    I believe this is precisely what many are afraid of.
    This isn't a change issue. This is about 3 releases no longer being compatible with their predacessors and some people not being comfortable with that. The same things that Tap5 is saying was said about Tap4. I remember reading about how Hivemind was better than Spring and that's why it was in Tapestry. The next version of Tapestry created a whole new IOC container and Hivemind is gone. If Hivemind wasn't good enough for Tapestry, why use it? And what if you believe that it was better and bet your project on it. You just got screwed. Considering what was said about Tap4 WRT to Tap3, why would Tap5 inspire more confidence? If each new release of a particular piece of software requires a rewrite of what's already in place, people are going to get balky. It comes down to one thing: Would you risk your job on a given piece of software given its track record? If you are can say yes, go for it. But consider that others may be skeptical based what's been put out to date.
  12. Re: FUD and Trolls[ Go to top ]

    I don't know, it all seems very logical to me. I think some of this is just an unfortunate parroting of a meme that may or may not be entirely true. 3->4 Before being involved in Tapestry as a developer I was actually building a very large product using T3. I personally went through the effort to upgrade from 3->4 and don't think it took me more than a single day to do the initial conversion grunt work. A great deal of it ~was~ backwards compatible. I guess other people have personal experiences where this wasn't true? I just followed the upgrade guide from 3->4 provided and went on my way. http://tapestry.apache.org/tapestry4/UsersGuide/upgrade.html The major change introduced here seems to be moving from "whatever people did before Spring came out with their crazy IoC idea" to an IoC based approach. I've not come across any open source library that lists spring as a dependency, so it does kind of make sense to me that an alternate / smaller / more tuned for Tapestry/Web container was created for this task. IoC was all the rage then right? 4->5 I think Howard already did a great job explaining how hard it is to adapt and evolve an API largely based around inheritance. It's maddeningly frustrating and slow. From what I can tell, Tapestry beginning -> Tapestry 4 were all evolved API changes mostly based around this same inheritance problem. I don't know how many years Howard/the others spent maintaining that line of code but I'm pretty sure it was substantial in terms of open-source time. The backwards compatibility issue with Tapestry 5 was a calculated risk. One that I think has paid off handsomely in terms of what Tapestry 5 is technically. The concepts / general organization / etc of a Tapestry app hasn't really changed all that much. It's all the internals and old cruft that have been removed. Yes, the fact that it hasn't been a drop in replacement for a seamless T4->T5 upgrade has angered some people - but we wouldn't be able to say it's the current most innovative / clean / mature component oriented java web framework available today. So, whatever - we're nerds and like to feel proud of our software. Sometimes you have to throw old shit out. I'm sure none of you have ever done that right? ;) Again, I think it's really just unfortunate parroting of troll/angry weirdo FUD that has let this misconception of things spread. We don't have all the time in the world and spending it arguing with people that aren't debating but more just screaming hysterically out of either legitimate concerns/jealousy/personal bitterness/whatever just isn't as much fun as writing code and doing other normal stuff with your time. I'd certainly risk my job for anything I believe in technically. I have done it in the past and will continue to do it because it's not a "job", it's something I love doing. Jobs will always come and go. etc..blah blah
    ..This isn't a change issue. This is about 3 releases no longer being compatible with their predacessors and some people not being comfortable with that. The same things that Tap5 is saying was said about Tap4. I remember reading about how Hivemind was better than Spring and that's why it was in Tapestry. The next version of Tapestry created a whole new IOC container and Hivemind is gone. If Hivemind wasn't good enough for Tapestry, why use it? And what if you believe that it was better and bet your project on it. You just got screwed. Considering what was said about Tap4 WRT to Tap3, why would Tap5 inspire more confidence?

    If each new release of a particular piece of software requires a rewrite of what's already in place, people are going to get balky.


    It comes down to one thing: Would you risk your job on a given piece of software given its track record? If you are can say yes, go for it. But consider that others may be skeptical based what's been put out to date.
  13. Re: FUD and Trolls[ Go to top ]

    .... I think it's really just unfortunate parroting of troll/angry weirdo FUD that has let this misconception of things spread. We don't have all the time in the world and spending it arguing with people that aren't debating but more just screaming hysterically out of either legitimate concerns/jealousy/personal bitterness/whatever just isn't as much fun as writing code and doing other normal stuff with your time.
    So basically you argue that everything that is said against tapestry 5 is parroting of troll/angry weirdo FUD/jealousy/personal bitterness while using a troll-like and passionate language on your own post?
  14. Re: FUD and Trolls[ Go to top ]

    It comes down to one thing: Would you risk your job on a given piece of software given its track record? If you are can say yes, go for it. But consider that others may be skeptical based what's been put out to date.
    The bulk of this entire thread is rubbish. Go sit down and take a look at the license (found here: http://tapestry.apache.org/license.html) and read this a few times: "Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE." Development rolled along smoothly for you using Tapestry 3, so there's a change in architecture from version 3 to version 4 and 5 and now your whole world comes apart? As far as I'm concerned if you evaluated the solution and couldn't assume the risk that down the road you'd run into problems such as newer versions not being compatible with T3, it looks to me like you really didn't do your homework very well, did you? Tom
  15. Re: FUD and Trolls[ Go to top ]

    +1
  16. Re: FUD and Trolls[ Go to top ]

    +1
  17. Re: FUD and Trolls[ Go to top ]

    versions not being compatible with T3, it looks to me like you really didn't do your homework very well, did you?

    Tom
    I actually did my homework quite well. My evaluated the risks and benefits and acted accordingly. I didn't use Tapestry and my work(and wallet) prospered. I never used Tapestry because I was unwilling to assume what I perceived as a risky, low marketshare, somewhat erratic, project on my teammates and customers and from where I stand, history supported that decison. I know people who wished they'd made the same decision. Regardless,I never said no one should use Tapestry, just that fiery individuals like yourself shoud seek to understand why others are reluctant to use it. You even quoted my point. Perhaps it is *you* who should read what you quote a few times and gain understanding.
  18. Re: FUD and Trolls[ Go to top ]

    It's getting to the point where I'd almost rather TheServerSide didn't post anything about Tapestry, since the only active members are FUDsters and Trolls.
    Howard, I'm sick and tired of the Tapestry community always choosing the quick and easy path of labeling people Trolls when they point out facts and things of legitimate concern. I disagree with you on the above statement and I know deep inside you, you know it's false. Howard, you intially created the front-end of TheServerSide with Tapestry, for god sake. Are you bitter because they dumped Tapestry and rewrote the whole stuff with a better technology? This community consists of some of the finest and knowledgeable you could find. On the contrary, the Tapestry list consists of fanatics and hypocrites. They are hypocrites because they fear to admit in public they only use Tapestry for toy-like projects and experimentations in the labs. Examining the release record of Tapestry and the over-engineered architecture of Tapestry 5, I see no reason a sane person would use it in a serious project. Unless that sane person smoked something during the decision making. To me, and many I'm sure, Tapestry is in coma dying a slow death. So guys, lets move on and leave this dead horse alone. Jan
  19. What's wrong with you?[ Go to top ]

    Jan, or should I say “Francis Amanfo” (probably your real name), Rob Smeets, Emmanuel Sowah etc. Your constant bashing of Tapestry makes me think you either have a personal grudge against Howard or you have some form of mental illness (or a combination of both ;)
  20. Re: FUD and Trolls[ Go to top ]

    To me, and many I'm sure, Tapestry is in coma dying a slow death. So guys, lets move on and leave this dead horse alone.

    Jan
    So let's get this straight, you don't work on Tapestry nor have you ever hence have control over the project in question. You decide to opinionate about this project and decree that it is "dead" (when it is obvious from this news item that people are using it and finding it useful) and you want to define what other people should or shouldn't do with their time and their lives ? About like that ? I'm sure a psychiatrist would have a field day with you.
  21. Re: FUD and Trolls[ Go to top ]

    You decide to opinionate about this project and decree that it is "dead" (when it is obvious from this news item that people are using it and finding it useful) ...
    Well, in the world of Opensource projects when we say a project is dead it doesn't mean no one is using it. Dead means the amount of users have reduced drastically and there is no development activity. Go and take a look at Sourceforge. There are so many dead projects but still have some few followers. I said Tapestry is in Coma and dying a slow death because there is still some development activity by Howard. It's only left for Howard to accept the failure gracefully and call it a quit. And I believe that time is coming sooner than you think. Regards, Jan
  22. Re: FUD and Trolls[ Go to top ]

    Howard, you intially created the front-end of TheServerSide with Tapestry, for god sake. Are you bitter because they dumped Tapestry and rewrote the whole stuff with a better technology?
    Jan, for the record, most of TSS is still in Tapestry. The site uses Jive forums for the posts now, as opposed to the older custom content management, but the site itself is still Tapestry.
  23. Re: FUD and Trolls[ Go to top ]

    Howard, you intially created the front-end of TheServerSide with Tapestry, for god sake. Are you bitter because they dumped Tapestry and rewrote the whole stuff with a better technology?
    Jan, for the record, most of TSS is still in Tapestry. The site uses Jive forums for the posts now, as opposed to the older custom content management, but the site itself is still Tapestry.
    Joseph, Well, thanks for the info. I have no access to the source code to verify this for myself, but my claim was based on a post here in the past that talked about this change from Tapestry. For readers interested, use the search box above and search through the archives then make the judgment yourself. Jan
  24. Re: FUD and Trolls[ Go to top ]

    Howard, you intially created the front-end of TheServerSide with Tapestry, for god sake. Are you bitter because they dumped Tapestry and rewrote the whole stuff with a better technology?
    Jan, for the record, most of TSS is still in Tapestry. The site uses Jive forums for the posts now, as opposed to the older custom content management, but the site itself is still Tapestry.


    Joseph,

    Well, thanks for the info. I have no access to the source code to verify this for myself, but my claim was based on a post here in the past that talked about this change from Tapestry. For readers interested, use the search box above and search through the archives then make the judgment yourself.

    Jan
    Oh, so "I saw a post somewhere" is a valid method of research? Again ... a crank (FUDster, Troll, whatever) is someone who claims privileged access to inflammatory information for which they actually know nothing. If you are keeping score, "Jan" has claimed (falsely): - That TSS "ripped out" Tapestry for some reason - That Tapestry's popularity is faltering - That Manning is not interested in book on Tapestry 5 - That "Jan" has a clean bill of mental health Looks like he's zero for four there!
  25. Re: FUD and Trolls[ Go to top ]

    You just gotta love "Jan", he's so desperate for attention. Notice that for him, the word of the Editor of TheServerSide is insufficient ... he want's access to the source code "to verify" and he's still clinging desperately to "some posting" he saw "somewhere" ("just search through the archives"). In other words, in his twisted world view, the random and fleeting posting by some other clueless moron still has more weight than a valid piece of information from someone who actually knows. As they say, "Never wrestle with a pig. You get filthy and the pig really likes it." I've let "Jan" sucker me in to the same pointless exchange as usual. To anyone watching from the sidelines: "Jan" will now start talking about a "conspiracy" of some form. Last time, he claimed I magically managed to get "blogger.com" to block his IP address.
  26. Re: FUD and Trolls[ Go to top ]

    Howard, I wrote the first reply, so I just want to let you know that I simply based my statement with facts. But actually, I really want to see future versions of Tapestry coming out, *without* breaking the API. I wish you the best and hope for good ideas, incredible ideas, and because most of us know how creative you are, I'm sure you will find a way to improve Tapestry 5, 6, 7 with this concern in mind. Specially, to avoid previous mistakes and start a new era for Tapestry. Cheers PS: anyway, sorry for the first post... I'm just an young troll full of fud =)
  27. Re: FUD and Trolls[ Go to top ]

    Howard, I wrote the first reply, so I just want to let you know that I simply based my statement with facts.

    But actually, I really want to see future versions of Tapestry coming out, *without* breaking the API. I wish you the best and hope for good ideas, incredible ideas, and because most of us know how creative you are, I'm sure you will find a way to improve Tapestry 5, 6, 7 with this concern in mind. Specially, to avoid previous mistakes and start a new era for Tapestry.

    Cheers

    PS: anyway, sorry for the first post... I'm just an young troll full of fud =)
    Backwards compatibility issues have been the thorn in Tapestry's side for several years ... thus the new design which will allow Tapestry to adapt to user code, not vice-versa, as new features roll out. Of course, to make it out of "Jan"s point of view, the fact that the framework evolved somehow retroactively breaks prior applications ... a silly thought. Many of my clients (from my years as an independant) are becoming Formos' clients, and are quite happy to get new training on T5 and help upgrading T3 and T4 apps to T5. Universally, organizations that have used Tapestry 3 and Tapestry 4 would prefer a magic upgrade path; but being more familiar for Tapestry's structure, understand about the changeover. The fact that you can run a T3/T4 app inside the same WAR as a T5 app makes it more reasonable to do a staged transition. If I singled you out for the "FUD" label, it's because ust saying "Tapestry 6" to me is like baiting a bear; T5 has taken 2.5 years oh hard work, experimentation, design and user feedback to get from initial coding to the release candidate (due in the next month) ... precisely so that there would not need to be a Tapestry 6.
  28. Re: FUD and Trolls[ Go to top ]

    Yep, "Jan". I can see from you clever, unsupported and inflammatory statement how wrong I was. This is a wonderfully enlightened place in which to have a free and open discussion.
  29. "Because Tapestry 6 will be totally a different architecture with the same way of thinking as the previous version."

    m2c
    C'mon why so sceptical about it?
  30. I was impressed[ Go to top ]

    Tapestry 5 is an extremely well built and well designed web application framework and I can hardly image there is another Java web framework that's more productive and versatile than Tapestry 5. It's build on Tapestry 5 IOC which allows you to virtually extend every part of the framework. It's live class reloading makes it extremely productive and fun to work with, the separation between markup and code and a component based approach results in clean code. Like any application framework it takes some time to get used to but once you have mastered the basics writing pages and components is really easy. I think everyone should give it a try, it impressed me Martijn Brinkers
  31. Re: I was impressed[ Go to top ]

    I think everyone should give it a try, it impressed me
    Ok, one should give Howard Lewis Ship a fifth and last chance.
  32. Re: I was impressed[ Go to top ]

    I think everyone should give it a try, it impressed me

    Ok, one should give Howard Lewis Ship a fifth and last chance.
    That's all that I ask, that's all that it'll take.
  33. "Because Tapestry 6 will be totally a different architecture with the same way of thinking as the previous version."

    m2c
    If you would take a bit of time to check why is Tapestry5 different from the earlier versions and why it actually might be the last major rewrite - you might find out that Howard could be right this time around. I have observed Tapestry since the early days and haven't hopped on the wagon until now. At first there was too much XML (and the rewinding concept seemed to awkward for my taste) - that was fixed in later versions. But still there was requirement to extend a bunch of base classes (similar to other web frameworks out there, e.g. wicket and even plain servlets). And that was the reason for having to break backwards compatibility with each major revision - the framework internals "leaked" into the application code (non-IOC approach). So, how is Tapestry 5 different, you might ask? Well, Howard has learned from past mistakes and removed the requirement to extend your view/controller/component logic from some Tapestry base class. You event don't need to implement any interface. Your logic is represented as plain java class with some Tapestry annotations thrown in. Some might dislike the extensive use of annotations but given the alternatives (extending base class), I'm more than happy to use them. And, Howard has put in some effort to reduce the number of annotations to bare minimum by allowing you to use naming conventions instead (e.g. event listener method names). How does Tapestry hook into my code if there is no requirement to extend some base class(es)? "Bytecode weaving" is the magic word here. During runtime, the bytecode of your view classes is modified to hook into Tapestry, according to the annotations and naming conventions. This is the mechanism that allows Howard to claim that future versions of Tapestry should be backwards compatible - in next version, Tapestry can weave different code to your view classes, leaving your code unmodified. In theory, that approach should make Tapestry application code (code written by you, the web application developer) 100% future proof. I say "in theory" because it only works as long as there is no conceptual change - as long as there are components, pages and all the other usual Tapestry concepts. Howard can add new concepts in future versions but he cannot change the contract of existing concepts. But he can freely change the implementation of those contracts, as long as the contract is maintained. This approach minimizes the number of constraints that "leak" from the framework implementation code to application code. Is there a possibility for a "conceptual change" that would render future version of Tapestry incompatible with Tapestry 5? Never say "never" - but considering the past Tapestry rewrites (the core Tapestry concepts haven't really changed since the early days) - I would argue that the probability for such a future change is very small. And if Howard will feel like making some radical changes in the core concepts - most probably the resulting project would not be called "Tapestry" any more. After I have outlined why Tapestry 5 is such a great framework - are there any downsides to using this runtime weaving approach? Well, there are. But Howard has taken steps to minimize their impact. At the top of the head, I can come up with two obvious limitations:
    • Performance impact - runtime weaving takes time (generating a class at runtime is CPU intensive). This it mitigated by Tapestry by reusing/pooling the generated classes and their instances (it has an internal pool). So you will have that impact only at startup (similar to JSP). In the future, Tapestry could also add a command line precompilation tool (similar to JSP-precompilation) - this would remove this concern almost completely (there still remains instantiation and initialization overhead at runtime). Maybe there already is such a tool - I'm just not aware of it.
    • Troubleshooting becomes more complex. Remember the good old times when your JSP had some (possibly compilation) error (with mysterious line numbers) and the only way to figure out what is wrong with it was to go and check the generated JSP servlet java source? This can be an issue also with Tapestry5, as Tapestry adds a bunch of code to your handwritten class and there can always be bugs in that code. And you have no java source to examine. Here Tapestry is making several steps to lessen this issue:
      • Line numbers in error messages correspond to the original source (has been a feature since the early days of Tapestry, even with non-java artifacts like configuration files)
      • Excellent error messages in general (well, most of the time at least)
      • Debugging should work just fine even with modified classes
      • If you need to see the java source of final generated class, you can turn on DEBUG level logging and you will see the java source of the final generated class being logged
    That was quite a long post, but I hope it clarified some justified concerns over Tapestry future-compatibility, given its poor track-record in this regard. I just don't like an excellent project like Tapestry5 being bashed at with no real arguments and just plain FUD. For the record: ever since the early Jakarta Turbine / Cocoon days (in 2000) I have been looking for a (component-based) web application framework that would fit my needs. It has been a long road for Tapestry but I think my search is finally over. I have already built one application on top of Tapestry 5 and although it still has some growing pains (related to the fact that it is still in beta) I can see that the foundation is solid and I'm looking forward to building many more applications on top of it in the future. Rgds, Neeme
  34. "Because Tapestry 6 will be totally a different architecture with the same way of thinking as the previous version."

    m2c
    You really have no better things to do other than provoke flame ? Anyone bashing a framework without using it first is a TROLL. I don't like Spring because of all the XML, and I say that by only seeing Spring features list. But I will not say that Spring is bad and that people shouldn't use it. If you have concerns for backward compatibility or any issue with tapestry, it would be nice if you would say so in a polite manner, and without making false statements like saying "there will be a tapestry 6 that will be totally different". If such thing happens I think it will not be in any near future. And if it ever happens you can still opt not to transfer, or use it for new projects as you may use any framework for a new project.. any how, I really dislike TheServerSide articles because of people like you. I've made an account just to posti to this thread. please look at: http://ars.userfriendly.org/cartoons/?id=20080822&mode=classic
  35. Guys, do you really migrate to a major version of your web framework in the middle of the project???
  36. +1 If anyone is not comfortable with the changes from Tapestry 4 to Tapestry 5, then those folks can gladly stick to tapestry 4. I love innovation and prefer the backward compatibility 'breaks'. And if I were Howard, I won't promise that changes in the future won't break previous versions. Positive changes simply keep the project relevant in the long term.
  37. wow what a way to develop framework[ Go to top ]

    so you are suggesting Flex, GWT and other popular framework should release new version which has no connection with previous version. Flex 4 should be radically different from flex 3 and GWT 1.5 should be so different that current GWT 1.4 apps should not work. If that happens so many client and developer go crazy and most of the application life cycle go into garbage. In that case everybody should deploy & write new app for latest version instead of focusing things on different business need.
  38. "Because Tapestry 6 will be totally a different architecture with the same way of thinking as the previous version."

    m2c


    You really have no better things to do other than provoke flame ?

    Anyone bashing a framework without using it first is a TROLL. I don't like Spring because of all the XML, and I say that by only seeing Spring features list. But I will not say that Spring is bad and that people shouldn't use it.


    If you have concerns for backward compatibility or any issue with tapestry, it would be nice if you would say so in a polite manner, and without making false statements like saying "there will be a tapestry 6 that will be totally different".

    If such thing happens I think it will not be in any near future. And if it ever happens you can still opt not to transfer, or use it for new projects as you may use any framework for a new project..


    any how, I really dislike TheServerSide articles because of people like you. I've made an account just to posti to this thread.
    please look at:
    http://ars.userfriendly.org/cartoons/?id=20080822&mode=classic
    Just because you don't like the message doesn't mean that it is invalid. It is a real concern. Most customers would react very poorly if you tell them their project needs a near total rewrite if they wish to upgrade to the new version. In addition, who's going to maintain Tap3 and Tap4 apps? Who would want to? Even Howard is said that customers want NEW training. I would say that if most open source projects did what Tapestry did, open source would not have the acceptance we enjoy today. I still remember having to sit in front of managers, sit in front of the dev teams, sit in front of customers and explain why we were, in essence, puting our fates in the hands of this "free stuff." You and others may not like it, Howard may gloss over it, but the fact remains that the all versions of Tapestry since 3 broke their predacessors. Spring at least at options other than XML. No offense to Howard, but wide acceptance and emulation of the Tapestry model would have serverely damaged,IMO, the entire open source movement. Think about it. How many of the successful projects so consistently do this? I can't think of any. You say "If such thing happens I think it will not be in any near future." But it has happened twice before. All the upgrades since Tapestry three. And the same things that are being said about Tapestry 5 where said about Tapestry 4. "A whole new framework that will make this sort of thing unnecessary in the future." Sorry. But prudence, and professionalism demands what one ignores the noise of the so-called Trolls and as well as individuals like yourself and stick to the facts. Fact: Tapestry 4 broke Tapestry 3. Fact: Tapestry 5 broke Tapestry 4. Fact: Hivemind was touted as being a superior choice for Tapestry 3. Fact: Hivemind is gone. Fact: Tapestry 4 had a new IOC container replacing the "superior" Hivemind. Fact:Now that(I think) is gone too, replaced by whatever is in Tapestry 5. There is something to be said for enhancing with new features and preserving one's work. At least that's important to me and the customers I've had. YMMV.
  39. I'm sorry, but your facts aren't really facts as they aren't true. Where are you getting your "facts" from anyways? Tapestry 4 did not "break" Tapestry 3. The only major change I noticed was the interface for engine services was changed slightly and had to be configured via hivemind instead of a .application file. So please, do tell us what you are basing your "facts" on?
    ..Sorry. But prudence, and professionalism demands what one ignores the noise of the so-called Trolls and as well as individuals like yourself and stick to the facts.

    Fact: Tapestry 4 broke Tapestry 3.
    Fact: Tapestry 5 broke Tapestry 4.
    Fact: Hivemind was touted as being a superior choice for Tapestry 3.
    Fact: Hivemind is gone.
    Fact: Tapestry 4 had a new IOC container replacing the "superior" Hivemind.
    Fact:Now that(I think) is gone too, replaced by whatever is in Tapestry 5.

    There is something to be said for enhancing with new features and preserving one's work. At least that's important to me and the customers I've had. YMMV.
  40. I'm sorry, but your facts aren't really facts as they aren't true. Where are you getting your "facts" from anyways?

    Tapestry 4 did not "break" Tapestry 3. The only major change I noticed was the interface for engine services was changed slightly and had to be configured via hivemind instead of a .application file.

    So please, do tell us what you are basing your "facts" on?

    ..Sorry. But prudence, and professionalism demands what one ignores the noise of the so-called Trolls and as well as individuals like yourself and stick to the facts.

    Fact: Tapestry 4 broke Tapestry 3.
    Fact: Tapestry 5 broke Tapestry 4.
    Fact: Hivemind was touted as being a superior choice for Tapestry 3.
    Fact: Hivemind is gone.
    Fact: Tapestry 4 had a new IOC container replacing the "superior" Hivemind.
    Fact:Now that(I think) is gone too, replaced by whatever is in Tapestry 5.

    There is something to be said for enhancing with new features and preserving one's work. At least that's important to me and the customers I've had. YMMV.
    I'm basing my facts on what I remember reading at the time. My understanding is that Tapestry 3 applications where not supported in Tapestry 4 and required considerable effort to port over. I stand ready to be corrected, but I've yet to see that corrrection. Besides my mistake that Tap4 contained Hivemind(which was corrected), I see that you didn't have much to say about my other points, which, I believe, is telling.
  41. That's precisely what I have corrected. I personally have upgraded a very large app from T3 -> T4 and found that the only required change I remember having to make was with engine services (we're talking maybe 2-3 small services to handle over-arching logic for whole app) and everything else was a bunch of deprecation warning log statements. What more am I supposed to do? What criteria do you use to evaluate whether or not you've been corrected? Your understanding is incorrect. Consider yourself corrected I guess.. =p
    I'm basing my facts on what I remember reading at the time. My understanding is that Tapestry 3 applications where not supported in Tapestry 4 and required considerable effort to port over. I stand ready to be corrected, but I've yet to see that corrrection.
  42. That's precisely what I have corrected.

    I personally have upgraded a very large app from T3 -> T4 and found that the only required change I remember having to make was with engine services (we're talking maybe 2-3 small services to handle over-arching logic for whole app) and everything else was a bunch of deprecation warning log statements.

    What more am I supposed to do? What criteria do you use to evaluate whether or not you've been corrected?

    Your understanding is incorrect. Consider yourself corrected I guess.. =p

    I'm basing my facts on what I remember reading at the time. My understanding is that Tapestry 3 applications where not supported in Tapestry 4 and required considerable effort to port over. I stand ready to be corrected, but I've yet to see that corrrection.
    My criteria? Howard. He read the same post you read and if he says I was wrong, I was wrong. No offense, but you seem to have a chip.
  43. HiveMind was introduced for Tapestry 4. Tapestry 5 has a new IoC container inspired by HiveMind and by Guice. Nothing "broke", any more than introducing WebWork 2 broke WebWork 1, or renaming WebWork 2 to Struts 2 broke Struts.
  44. HiveMind was introduced for Tapestry 4.

    Tapestry 5 has a new IoC container inspired by HiveMind and by Guice.

    Nothing "broke", any more than introducing WebWork 2 broke WebWork 1, or renaming WebWork 2 to Struts 2 broke Struts.
    Thank you. You refined my facts, but proved my point. Go back and replace the appropriate instances of Tapestry 3 with Tapestry 4 and my facts, I believe, stand. You didn't dispute my other items. However, I don't think you are doing the Struts a disservice. Struts went with Webwork because, I suspect, of the enormity of bring Struts into the preset. This was one breaking change. Tapestry did this twice. Again, I'm not saying you were wrong or that one should not (or should) use Tapestry. What I *am* saying is that people, especially you, should understand why some would be gunshy about Tapestry given its history. To be honest, I don't understand why this very valid concern is under dispute.
  45. Nothing "broke", any more than introducing WebWork 2 broke WebWork 1, or renaming WebWork 2 to Struts 2 broke Struts.
    Struts is a team project. Struts and Struts2 are considered peer projects and are developed in parallel, at least officially. There are committers who still develop Struts (should I call it Struts1 for clarity?), there are users who still use Struts, there are users who still file tickets against Struts, and there are committers who resolve these issues. Struts and Struts2 are independent projects. Struts is not dead, yet.
    Many of my clients ... are quite happy to get new training on T5 and help upgrading T3 and T4 apps to T5.
    Sure they are.
  46. Look what I can do with s/Struts/Tapestry:
    Tapestry is a team project. Tapestry 4 and Tapestry 5 are considered peer projects and are developed in parallel, at least officially. There are committers who still develop Tapestry 4, there are users who still use Tapestry 4, there are users who still file tickets against Tapestry 4, and there are committers who resolve these issues. Tapestry 4 and Tapestry 5 are independent projects.
    Jesse, Marcus and Andreas are still active on Tapestry 4. In fact, there's a discussion right now about a new Tapestry 4.1 release. Kevin, Dan and Igor and myself are mostly invoked in Tapestry 5.
  47. "Because Tapestry 6 will be totally a different architecture with the same way of thinking as the previous version."

    m2c
    In fact, Tapestry 6 is already here, and its name is Click, only much better ;-)
  48. "Because Tapestry 6 will be totally a different architecture with the same way of thinking as the previous version."

    m2c
    But Tapestry 6 is already here! Its name is Click and is has all the advantages Tapestry claimed to have long ago but never fully delivered: Click is component oriented, extensible, has a good documentation and example apps, it is very efficient, and has everything you need except the huge learning curve: it's very easy too learn, and the API is stable and open. Give it a try and you will start writing your first production quality web app within a week. And it's going to be soon in the apache incubator. So Tapestry 5, why bother?
  49. It seems David McCoy and Jan de Jonge are Trolls, based their facts in speculation as McCoy said he got some facts because he read from Tapestry 3 era articles?, What the hell is that?, this people doesn't have experience or even touched Tapestry and they are bashing Tapestry and speculating with just reading articles from the Internet!, This people for sure are "Big Fat Trolls". Software need rewrites at some point because errors, we are human not robots we mistake all the time so we have to rewrite our software at some point. Tapestry 4 as Howard said is still supported and it will be for a long time so people have projects with Tapestry 4 doesn't need to rush to update to Tapestry 5. This is the same thing as the case with Struts 1 and Struts 2, JSF 1 to JSF 2 is a complete rewrite, Tapestry 3 to Tapestry 4 it was little changed and to Tapestry 5 just need to re factor your classes because now are just POJO's, I don't see any problem with Tapestry Roadmap. Also people have their own choice, some likes Tapestry, others JSF, others Click, Others Wicket. Lets respect each other decision and stop bashing Frameworks because it is to much work just to create one with a community and all is one complete process and takes years to build. Talking about frameworks, Mr.Jan de Jonge always claim he is building a killer framework based on Tapestry or Wicket?, where the hell is that framework?, Jan you should use your time more to really experience what is to build a framework and a community and stop wasting the time of everybody with your FUD, you dam Troll!.
  50. Marketing issue[ Go to top ]

    For me, the version change breaking thing is an issue. But it is a marketing issue. If instead of naming it Tapestry 4 and Tapestry 5 a new name was given to the framework, nobody would have complain. Migration to a new version of a framework, so far I've never seen that happen. You pick a framework for a project, and if a new version comes out, you'll use it for the next project, if you can. The only real issue here is documentation and books. If new version is different, old book is outdated, lack of resources for learning -> low customer base. Giving different name to the different version kind of solve that issue too. Your search for learning resources doesn't come up with irrelevant/outdated results. Well, that's how I see it, that's why I see Tapestry as an interesting framework but that will always have a low user and customer base. Just like many many other frameworks out there. That's not a good thing or a bad thing. PS: on a side note, does anybody know why all the 'Post reply', 'printer friendly',... buttons of TSS aren't working on my Opera?
  51. It seems David McCoy and Jan de Jonge are Trolls, based their facts in speculation as McCoy said he got some facts because he read from Tapestry 3 era articles?, What the hell is that?, this people doesn't have experience or even touched Tapestry and they are bashing Tapestry and speculating with just reading articles from the Internet!,Jan you should use your time more to really experience what is to build a framework and a community and stop wasting the time of everybody with your FUD, you dam Troll!.
    You, sir, are the perfect example what what is wrong with the internet. People like you, hidden in your basement, say things you would never have the guts to say to someone's face. I *GUARANTEE* that you would never insult me face to face. What I stated, I read from Howard Lewis Ship, who has graciously responded, but expect for my mistake about Hivemind and Tapestry 3 hasn't disputed anything I've written. It has been years since I saw his posts on the subject, and as I said, look forward to any correction he sees fit to offer. I never said that anyone shouldn't use Tapestry. I've said several times that it is reasonable to have concerns about the project based on its history. Obviously, the difference, though gross, is beyond you.
  52. @David McCoy, You are still insulting this thread with your postings!. We don't need trolls as you bashing good frameworks without real facts, Also I don't give a shit who are you and If I see you face to face I will insult you I *GUARANTEE* you. Who the hell are you to tell me what kind of person I am, Bullshit really full of BS!!. hmm... I getting to realize that I'm feeding the troll. Anyway Tapestry 5 Rocks really people and people please don't fell or follow this Trolls FUD. I'm done with this thread, Regards.
  53. @David McCoy, You are still insulting this thread with your postings!.

    We don't need trolls as you bashing good frameworks without real facts, Also I don't give a shit who are you and If I see you face to face I will insult you I *GUARANTEE* you. Who the hell are you to tell me what kind of person I am, Bullshit really full of BS!!.

    hmm... I getting to realize that I'm feeding the troll.

    Anyway Tapestry 5 Rocks really people and people please don't fell or follow this Trolls FUD.

    I'm done with this thread, Regards.
    No, you wouldn't. Your kind never does anything face to face. You cannot even have a civilized discussion caused by nothing more than a simple disagreement. I'm confident that you don't conduct your affairs in your place of employment in such a manner. No one starts insulting and cursing so quickly, at least no one sane... Be that as it may, I believe that my point has been made.
  54. Too bad you are the only one who knows what it was/is.
    ..Be that as it may, I believe that my point has been made.
  55. If I see you face to face I will insult you I *GUARANTEE* you.
    Wow, the Tapestry community really doesn't like disagreement. Good to see that the development team responded to the criticism in a cool and professional manner, rather than taking it personally.
  56. Good to see that the development team responded to the criticism in a cool and professional manner, rather than taking it personally.
    I disagree with this comment. Go back and re-read the responses from Howard. Some of them were personal and unprofessional.
  57. I would suggest all TSS reader to briefly read some messages posted by Jan (ehh Francis Amanfo) to see who the real troll is. I guess he should seek some professional help
  58. I would suggest all TSS reader to briefly read some messages posted by Jan (ehh Francis Amanfo) to see who the real troll is.

    I guess he should seek some professional help
    This idiot Martijn Brinkers keeps linking me to names I'm unfamiliar with. I hope those bearing these name would one day come to find out and react on this stupidity. You seem to me like a child who still needs to grow. Boy, leave here, ok? Jan
  59. I disagree with this comment. Go back and re-read the responses from Howard. Some of them were personal and unprofessional.
    Nonsense, Howard Lewis Ship is highly professional, he is far too mature to take an internet troll, such as your self, seriously and Tapestry 5 represents the future of web application development. Any developer who doesn't immediately place their faith in the development team is a cad of the highest order and shall be first against the wall when the revolution comes. The future is bright, the future is woven.
  60. If I see you face to face I will insult you I *GUARANTEE* you.

    Wow, the Tapestry community really doesn't like disagreement.

    Good to see that the development team responded to the criticism in a cool and professional manner, rather than taking it personally.
    Well, if these responses are from members of the tapestry community (i.e. calling people Trolls) then that enough will keep me away of that framework.
  61. Oh, please Tapestry team, please hurt me more! Please sell me on your great framework and then get distracted by shiny new features that break backward compatibility so that I can explain to non-technical people why renovation projects require complete re-writes! Thank you for spanking me good and hard with your arrogance! I love it. Also, Howard, your beard is hot!
  62. Oh, please Tapestry team, please hurt me more! Please sell me on your great framework and then get distracted by shiny new features that break backward compatibility so that I can explain to non-technical people why renovation projects require complete re-writes! Thank you for spanking me good and hard with your arrogance! I love it.

    Also, Howard, your beard is hot!
    i guess too many open source projects start off with lots of promises and then suddenly a lead developer leaves for another shiny object or suddenly realizes he has to pay his bills, the whole project goes down the drain. Everyone has bills to pay, but the bills we developers who depend on these tools /apis / frameworks have to pay are way too high. i think there is no serious java developer out there who hasnt been burnt by an open source compatibility issue. if you depend on open sopurce stuff - remember it has its own baggage ( no documentation, poor support, compatibility issues ). but hey its free so suck it up or dont use too much of it :). i m on the "dont use too much of it" wagon for some time. its great and you realize that simple out of box java, j2ee gives you so much already that you dont miss open source after a while. :) ... no kidding. try it
  63. i m on the "dont use too much of it" wagon for some time. its great and you realize that simple out of box java, j2ee gives you so much already that you dont miss open source after a while. :) ... no kidding. try it
    Speaking of FUD and trolling. Guess nobody told you that Java is Open Source now ;). Besides there are a lot of other projects that save you a lot of time/effort/embarrassment and are also VERY stable through releases with good documentation (plenty of good books, and what best documentation that well commented source code/unit tests) and support (very participative forums and responsive issue trackers): Spring, Hibernate, Tomcat to make some examples. And in my experience closed source has pretty bad documentation, and plenty of incompatibility issues, and defective tools: try "Websfear" or OAS.
  64. i m on the "dont use too much of it" wagon for some time. its great and you realize that simple out of box java, j2ee gives you so much already that you dont miss open source after a while. :) ... no kidding. try it


    Speaking of FUD and trolling.

    Guess nobody told you that Java is Open Source now ;). Besides there are a lot of other projects that save you a lot of time/effort/embarrassment and are also VERY stable through releases with good documentation (plenty of good books, and what best documentation that well commented source code/unit tests) and support (very participative forums and responsive issue trackers): Spring, Hibernate, Tomcat to make some examples.

    And in my experience closed source has pretty bad documentation, and plenty of incompatibility issues, and defective tools: try "Websfear" or OAS.
    how can i forget tomcat - my old and faithful web container. apologies.. I agree - Apache , spring and some other bigs guys like jboss are well documented. (although i had issues with axis upgrade once as it needed latest commons and xerces and i couldnt make tomcat work with those versions :) ) but you know what i really meant - of the thousands of open source "news releases" i read here on TSS, there are only a handful you can rely on.
  65. i m on the "dont use too much of it" wagon for some time. its great and you realize that simple out of box java, j2ee gives you so much already that you dont miss open source after a while. :) ... no kidding. try it
    I couldn't agree more. I follow the same school of thought where I don't want to use any thing outside the J2SE and J2EE stack, unless I really don't have any option. The biggest advantage of this approach is code maintenance because what you are writing is standard. Always remember "learn once and apply every where" But even I have to admit when it comes to presentation tier, Java sucks big time, the last time I checked no one in the right mind want to use JSF. I am amazed years of community involvement and wastage of time, but still JSF is virtually no where.
  66. when it comes to presentation tier, Java sucks big time, the last time I checked no one in the right mind want to use JSF. I am amazed years of community involvement and wastage of time, but still JSF is virtually no where.
    I disagree. Besides JSF (of which I'm not a fan, but the next version should see considerable improvements), there are frameworks that should fit any need and style out there. Stripes and Click if you want a good model 2 framework. Rife if you like things to be flow-driven and modular. GWT and Echo if you want an statically typed OO framework for building Ajax apps. Wicket if you want the same, but want to support traditional web apps besides Ajax. Tapestry if want that mixed model, but with a declarative programming model. Grails if you're in the dynamic camp. Heck, I'd even call Flex a Java framework, because it integrates so well with Java. I think there's plenty of choice, if Java is great for doing web apps. It's all in the choices you make on top of it.
  67. if you depend on open sopurce stuff - remember it has its own baggage ( no documentation, poor support, compatibility issues ). but hey its free so suck it up or dont use too much of it :).
    That is true for plenty of open source projects, but there are also plenty that are very well documented, and closed source projects can just as well be horribly documented (if you look past the glossy leaflets) and poorly supported (only support when you buy it, and even then in my experience they don't always fix problems promptly). More importantly, compared to closed source, you always have a way out with open source; you can always fix your own bugs. Certainly when it comes to Java frameworks.
    i m on the "dont use too much of it" wagon for some time. its great and you realize that simple out of box java, j2ee gives you so much already that you dont miss open source after a while. :)
    I think it is always good to make a critical assessment of whether you need certain dependencies or not. I would agree with you if you had just mentioned out-of-the-box Java. J(2)EE however? Really? Even with the much improved new version of JEE I believe most folks are better off using just the standard edition with a few best-of-breed open source frameworks. And I would place Tapestry in that category.
  68. I was a struts user until I decide to learn a new component based framework. I looked at Wicket at first, it seems easy and have good features but when I begin to work with it I could not resist the verbose of the framework, I have to declare all the gui on the code and in the markup on the same time, It is like programming swing on the web, Swing is great for desktop GUI Apps but not for web apps it breaks the methology. Really I didn't like Wicket and it is bloated. Tapestry 5 is so good quality, compact, not verbose, it is a snap to create a component, very easy to use, clean, wow is a refresh. So now I'm a Tapestry 5 user, sorry for the Wicket guys but really Wicket is an ugly framework. If I need to do Ajax/Web2 I will use a full implementation as ZK Framework one of the best, Dojo with DWR or really go with Flex3.
  69. Swing is great for desktop GUI Apps but not for web apps it breaks the methology.
    Nah. Stateful widgets are great concepts, and have been one of the driving forces behind the development of object oriented programming. I think most experienced people will agree that the advent of web applications set back software engineering practices a decade. Now with Ajax and component oriented frameworks, we're creeping back to the situation where you can reap the benefits of object orientation again. It's been pretty bad for a while, and some ideas that I think conflict with oo, such as page flow, are unfortunately hard to beat.
    So now I'm a Tapestry 5 user, sorry for the Wicket guys but really Wicket is an ugly framework.
    It's funny you think you might hurt someone by preferring another framework. Everyone their own cup of tea. At least you gave it a try. :-)
  70. I have to declare all the gui on the code and in the markup on the same time
    In Wicket you bind components (data models, event listeners) in Java to almost pure HTML code, is this a problem for you? Do you prefer obscure components with HTML generated behind the scenes by the framework? Note: I'm not involved in Wicket, I'm the author of ItsNat which shares with Wicket this idea of binding Java components to pure HTML.
  71. @Jose Maria Arranz, I will reiterate I didn't mean Wicket is bad it is just I prefer how Tapestry 5 do. Yes I prefer the behind the scenes generated by the framework but it is not obscure components it is that the component is just a POJO with a few annotations and you wrap the Javascript and css if you are adding Ajax to your new Component but you could reuse the framework component and also it is not an obscure component check the Tapestry 5 code and you will see what I'm talking about it is very clean and all are simple POJO's. Also with Tapestry 5 I can render components/pages totally programmatic, code and mark up Ala Wicket or totally markup/declarative. My point is that Tapestry 5 is very flexible, easy of use and not bloated to my taste. Also Tapestry 5 includes its own IoC and support Hibernate out of the box so I have a complete stack to work. If you like Rails I'm sure you will like Tapestry 5 it is that productive feeling I have with Tapestry5. Regards.
  72. The main problem I have with Wicket to be honest is the HTML artifact. The fact that I have to say, add a button in both HTML and java code does seem tedious and laborious to me. (Please I'm not trying to flame here). I'm still not 100% sure what the benefits of this approach are. It seems to me when using more sophisticated components the HTML just deteriorates to a list of DIVs with ids anyway. If a component can document what it emits in terms of Ids and CSS classes , I would prefer not to have to do this tedious updating of HTML and just get on with writing java. I really do feel that an Object Oriented approach is a great fit for writing webapps. As Eelco says elsewhere, the document oriented webapp approach set us back years, but Wicket seems to sit on the fence here, ie. it still hangs on to the document approach (ie. HTML). Personally, I'd prefer if I could just do it in java and have an even more Swing like approach. This is the Echo approach, - unfortunately Echo is just too poorly documented and still too esoteric and lacking in popularity for me to go with. My boss just won't be comfortable with it without good documentation and ideally a few books. I really wish that Wicket could run in 2 modes, - maybe with HTML, and also a HTML"less" mode. - Then I'd make the move to Wicket! Perhaps this suggestion is just daft, - but I am curious as to whether it would be possible?
  73. To add to the above, if Wicket were to do away with the HTML artifact, components could simply be documented with sample or default CSS for customizing the look and feel of the component.
  74. Actually, there is nothing stopping you from hiding these "HTML artifacts" by creating a framework on top of Wicket that does exactly what you're talking about. This is in some sense a disjoint subset of the Wicket RAD vision (earlier my Wicket on Wheels idea) which will allow you to drive web user interfaces (and not just auto-bean forms) either from code or HTML. You really want both in my opinion.
  75. BTW, if some interested party or parties wanted to fund Wicket RAD, Wille Faller has got a solid if basic start which serves as a nice POC and I have some interesting thoughts about how to approach this problem in a wider context. The result would be far more rapid and extensible than ROR, but without all those ROR downsides I hear people talking about. And actually, I'm curious if some of these ideas could also be applied to Tapestry or other frameworks...
  76. Personally, I'd prefer if I could just do it in java and have an even more Swing like approach. This is the Echo approach, - unfortunately Echo is just too poorly documented and still too esoteric and lacking in popularity for me to go with. My boss just won't be comfortable with it without good documentation and ideally a few books./blockquote> Check out Eclipse RAP and GWT then.
  77. Personally, I'd prefer if I could just do it in java and have an even more Swing like approach. This is the Echo approach, - unfortunately Echo is just too poorly documented and still too esoteric and lacking in popularity for me to go with. My boss just won't be comfortable with it without good documentation and ideally a few books.
    I think GWT would be an excellent choice then. Wicket and Tapestry made the deliberate choice not to work with layout managers but depend on (x)html for that, and if that's not your cup of tea, don't fight it, but use something that suits you better. Like I said before, that's great about Java for web apps... plenty of choice :-)
  78. Personally, I'd prefer if I could just do it in java and have an even more Swing like approach. This is the Echo approach, - unfortunately Echo is just too poorly documented and still too esoteric and lacking in popularity for me to go with. My boss just won't be comfortable with it without good documentation and ideally a few books.


    I think GWT would be an excellent choice then. Wicket and Tapestry made the deliberate choice not to work with layout managers but depend on (x)html for that, and if that's not your cup of tea, don't fight it, but use something that suits you better. Like I said before, that's great about Java for web apps... plenty of choice :-)
    I agree with you. My last "from scratch" project was GWT and it was a joy. I don't enjoy HTML and detest javascript and am willing to consider anything that keeps me as far away from both as I can get. And for my money, GWT's method of creating components is the best I've *worked* with. I would say best I've seen,but perhaps some are better than they looked...*to me*, but I haven't worked on any non-trivial projects with them. I truly enjoyed my time with GWT and look forward to my next GWT project.
  79. GWT[ Go to top ]

    I truly enjoyed my time with GWT and look forward to my next GWT project.
    I haven't actually used it, but I like what I know from GWT. It's not an option for everyone though, and it has it's own strong and weak points. Of the top of my head (and not the most recent info, so correct me if I'm wrong), I would say some of the strong points are the nice API (OO, woohoo), great that it is backed by Google, nice community, nice tooling, and just in general a very smart idea. Some cons are imho that you'll have to pay more attention to security issues (compared to Wicket at least), that it lets you develop applets rather than a whole web site (no integrated solution bookmarkability for instance), and that it is Ajax only. And I'm not convinced I would want to trade the flexibility and preview-ability of working with templates for working through layout managers. Anyway, GWT would definitively be in my top 5 of frameworks to consider for a new project (probably would be between Wicket, Tapestry, GWT, Flex and Lift for me).
  80. GWT and Wicket[ Go to top ]

    Yes, I do find GWT v. interesting and its an obvious one deserving of scrutiny. I do prefer the server side nature of Wicket though (ie. as you say, security and also a conventional build and debug environment). I also feel that the availability of widgets is better for Wicket (ie. with wicket extensions and wicket stuff), - GWT's widget library is a bit lacklustre for my liking, yes there are opensource and commercial widget offerings for GWT, but with dubious or confusing licensing (ie. GWT Ext/ext-GWT). I do however, prefer the pure Object Oriented approach of GWT. As you say, it's great to have choice though.
  81. The main problem I have with Wicket to be honest is the HTML artifact. The fact that I have to say, add a button in both HTML and java code does seem tedious and laborious to me. (Please I'm not trying to flame here).
    I can see where you are coming from and sometimes it can be annoying but I actually have come to see the HTML artifact as a strength. The key is to keep the number of dependencies between the HTML and the code to a bare minimum. Ideally there will be a lot of things in the HTML that have nothing to do with your code such that much of the presentation is in the HTML. If you feel that the HTML and the corresponding code are 1-to-1, then you may be missing some of the cool things you can do with Wicket.
    I really wish that Wicket could run in 2 modes, - maybe with HTML, and also a HTML"less" mode. - Then I'd make the move to Wicket!
    Perhaps this suggestion is just daft, - but I am curious as to whether it would be possible?
    I don't think this is 'daft'. I'm no Wicket expert but it seems to me that based on what I know of the architecture, this could probably be done as an add-on to Wicket. I think you would just need a way to generate the base HTML to replace the static files Wicket depends on and a way to 'trick' Wicket into using it.
  82. I really wish that Wicket could run in 2 modes, - maybe with HTML, and also a HTML"less" mode. - Then I'd make the move to Wicket!
    Perhaps this suggestion is just daft, - but I am curious as to whether it would be possible?


    I don't think this is 'daft'. I'm no Wicket expert but it seems to me that based on what I know of the architecture, this could probably be done as an add-on to Wicket. I think you would just need a way to generate the base HTML to replace the static files Wicket depends on and a way to 'trick' Wicket into using it.
    Yeah, the framework is pretty extensible, and you can take things pretty far if you're willing to build your own framework out of it. However, personally I think it is a good idea to have a clear focus for a framework, and not working through layout managers but instead using regular xhtml is one of the fundamental decisions we made early on. There are some advantages to that, the most important ones (imho) transparency and the ability to go from prototype to implementation and back again (or even use web designers for that). But sure, every once in a while I hate html as much as anyone :-) My uneducated guess is that Tapestry is flexible enough to implement some kind of layout manager on top of it as well. Maybe Howard has some war stories about that, or anyone else reading this did that (it's a Tapestry thread after all)?
  83. sorry for the Wicket guys but really Wicket is an ugly framework.
    I'm a Tapestry user and I disagree with that statement. I tried several web-frameworks and I've built fairly large applications with Tapestry 3, Tapestry 4, Wicket and now Tapestry 5. This pretty much also sum up my order of preference. I used Tapestry 3 back in the days because Wicket was still too early in its development and very session-heavy which made Tapestry 3 a much better candidate for that specific project. The app is written in Tapestry 3 and will stay in Tapestry 3, rewriting it to T4 or T5 is too much work (expensive) without functional benefits. So it is a hard sell to the customer, although it is getting harder and harder to find developers that know Tapestry 3. Tapestry 4 was/is much better than Tapestry 3, but currently I prefer Wicket over Tapestry 4. Tapestry 5, in my opinion, is better than Wicket again. But there is no need to call Wicket ugly. It is an excellent framework a lot of people find a joy to use and I have been happy to use it as well. Keep in mind that T5 was released later and was inspired by other ideas from other frameworks and the huge improvements couldn't have been built in if Howard would have to keep backward-compatibility in mind. I'm glad he let go and redesigned T5 from scratch. The biggest downside to Tapestry I think, is its steep learning curve. You really have to know your way around the available services and annotations before you are productive. Wicket makes it easier because of the interfaces and superclasses. The auto-complete functionality of your IDE helps a lot when you just get started with Wicket and it doesn't in Tapestry. But once you know your way around T5, it is very productive and very easy to use.
  84. I don't want to start a flame war about Wicket vs Tapestry its just my opinion and experience with Wicket. Yes I'm sorry, I didn't mean ugly, Wicket is cool and have good features as I said, I should write it is not for my taste. I think this is personal taste, I like more Tapestry 5 approach than Wicket approach at this time(the thing about the code and markup at same time and the Swing feeling for the Web). But yes as you said Wicket is not bad at all, for another people is great, I'm agree in something, that Tapestry and Wicket are much better than JSF or Struts. Anyway to Wicket people great job with Wicket 1.4 is coming and Tapestry people for the 5 RC is coming. Best Regards.
  85. Good Job Howard[ Go to top ]

    I can't wait to start a Tapestry 5 based project.
  86. Re: Good Job Howard[ Go to top ]

    All the trolls that whine about Tapestry rewrites are dinosaurs that are afraid of change, new technology, looking forward. Really this people should not be programmers they should be bureaucrats. I said it many times all the software at some point suffer rewrites to get to the perfection because there are some mistakes in the past and that is experience acquired. Ruby 2.0, Python3000, M$ technology, Java desktop with JavaFX and many many more suffered rewrites at some point. Tapestry 5 architecture is very good quality, one of the best I have seen and very stable. Howard already said there will not be anymore Tapestry 6 rewrite, Tapestry is now very mature and really is a top notch framework to create great projects. I wished JSF was like Tapestry 5 even JSF 2 I still dislike. Howard congratulations for your job and we are lots of people that love Tapestry5. I'm looking forward for a Tapestry 5 RC. Best Regards.
  87. Re: Good Job Howard[ Go to top ]

    Ah by the way, We just need a new Manning Tapestry 5 in Action book and all will be set. Regards.
  88. Re: Good Job Howard[ Go to top ]

    Ah by the way, We just need a new Manning Tapestry 5 in Action book and all will be set.

    Regards.
    Don't bet your hard dollars on it. Manning has decided not to accept any Tapestry in Action book publication request, at least not from Howard Lewis Ship. Because they say the last Tapestry in Action book was a big failure. If you want a confirmation on this send an email to manning and I'm sure they'll happily reply you. I should also mention I heard this some years back when Tapestry 4 came out and Howard was planning to upgrade that book. Maybe they've changed their mind now, though I doubt it. Regards, Jan
  89. Re: Good Job Howard[ Go to top ]

    The first rule of spotting a crank: someone who claims to have "inside knowledge" in an area they know nothing about. Yep, I'm sure you're best buddies with Marjan. I'm still getting modest royalty checks from Tapestry in Action.
  90. Re: Good Job Howard[ Go to top ]



    I'm still getting modest royalty checks from Tapestry in Action.
    Howard, Please help me here with what you mean by "modest". It reminds me of a company I knew that for several years barely generated any revenue. At one point in time they published a newsletter claiming a successful year because their revenues for that year had grown by 300%, without they stating the final amount. After some research it became evident that their claim was right. But that 300% increase was based on $1,200 from the previous year. Whereas in their business plan they had predicted a revenue of $400,000 for that year. Of course from $1,200 to $3,600 would seem modest to them. But comparing that to what they had predicted, thus $400,000, it was a total failure. From then they went into a deep coma. And eventually, they died. So, I hope the odor I'm smelling from your "modest royalty" story doesn't smell like that, Mr. Ship. Jan
  91. Re: Good Job Howard[ Go to top ]

    Here Jan, http://www.nytimes.com/2008/08/03/magazine/03trolls-t.html . (is that you in the image? ) Perhaps reading this article will give you a chance to reflect on your actions and how you spend your free time. The first step towards getting better is to acknowledge that you have a problem.
    ..blah blah blah..blah. So, I hope the odor I'm smelling from your "modest royalty" story doesn't smell like that, Mr. Ship.

    Jan
  92. Re: Good Job Howard[ Go to top ]

    Howard already said there will not be anymore Tapestry 6 rewrite, Tapestry is now very mature and really is a top notch framework to create great projects.
    Skander, You seem to not have seen the earlier post by David McCoy. I'm quoting it here for you:
    While the language is strong, is the concern unwarranted? Tap5 breaks Tap4 which broke Tap3. I did look at Tap3 back in the day and actually started that process of bringing the management on board. But when Tap4 came out, I held out, and to be frank, I was glad. It broke Tap 3. Was this a one time thing? You said Tap4 was a "from the ground up" change, right? "Includes better IOC than Spring(or Hivemind(which was better than Spring))", right? How would I have looked when the Tap5 beta came out stating that Tap4 apps weren't supported? What if I'd moved stuff to Hivemind, which is gone? You can have an open mind, but the track record(and one's job security) demands healthy skepticism, does it not?
    This clearly tells you that Howard Lewis Ship is not credible. He has said those words you wrote before but look at where we are now. There is definitely a Tapestry 6 coming. And you don't need a crystal ball to predict it'll also break backwards compatibility. Some food for thought for you. Good luck though. Jan
  93. Re: Good Job Howard[ Go to top ]

    All the trolls that whine about Tapestry rewrites are dinosaurs that are afraid of change, new technology, looking forward. Really this people should not be programmers they should be bureaucrats.
    I don't know about you, but I produce code for the long term. My clients rarely have the budget for major rewrites. It would be unprofessional to pick anything that didn't appear to provide a stable API and long term support. While you are correct that rewrites are sometimes necessary, you have to consider the frequency and severity. Considering it's track record, it's very difficult to consider Tapestry a safe bet for the future, so we won't ever use it. I'm sure that the Howard & the other contributors have put a lot of work into it, and it's probably pretty good, but we have to consider more than just the code. Sadly, at this point it's not even worth including it for evaluation.
  94. Tapestry is well worth using[ Go to top ]

    I can only supply my experience. T3 was great, T4 improved in a number of areas as well as introduced an IOC architecture. The upgrade path really was not difficult at all. Certainly no harder than other major upgrades for other major libraries I have used. T5 is a major leap forward again. Upgrading is a little more involved but not that big a deal. My view is that it is a major version hence, for me, total backward compatibility is not required. A lot of fat has been cut which provides a superior API and performance - all good aspects as far as I am concerned. I would rather the library stay valid and a leader than fall behind. My Hat is off to Howard's effort and his continual work to make this product one of the best (if not the best [which is subjective]) web framework out there. At the end of the day it your choice so use what you feel is appropriate.
  95. Tapestry 5[ Go to top ]

    I tried Tapestry 5 in sept/oct 2007. It took me more than a day to build a simple form (I couln't find any useful examples how to build a form app)! I think Tapestry takes more time than usual to get really productiv compared to frameworks like JSF or Wicket. If you want/have to build your own components Tapestry might possibly be simpler than e.g JSF but its a hard way to get there in Tapestry. I (currently) prefer Wicket because it has good documentation and useful examples to start with.
  96. Re: Tapestry 5[ Go to top ]

    I (currently) prefer Wicket because it has good documentation and useful examples to start with.
    LOL. I think you should see the current T5 docs first now. It's really clear, well structured and well explained.
  97. How about portlet support[ Go to top ]

    I understand portlet support is one of the casualties of the rearchitecture to Tapestry 5 - are there any concrete plans to re-add portlet support?
  98. Re: How about portlet support[ Go to top ]

    That will arrive as a follow on release, probably in 5.1. Right now I'm trying to nail down a few things to get the release candidate out.
  99. I seem to be going against the flow here, but I think it is fine that Tapestry has big API breaks between major releases. The source code of older releases is available to anyone who wants to have it, so bugs can always be fixed, either by the community that keeps using the older versions, or if things get bad, you can fix it yourself or hire someone to do that for you. I'm not a Tapestry user, so what I'm saying here might be wrong, but it sounds to me like the biggest mistake Tapestry made in the past was not so much in breaking the API, but in neglecting to make a strong case to the community why that had to be done AND providing a clear upgrade path from older to newer versions. Imho things only get really dramatic when non-trivial features of past versions are in no way supported in new versions. However, I had a few issues with other frameworks (Hibernate and Spring for instance) that had silent breaks between releases. In some cases something stopped working, or worked differently, without even giving a hint why. I hate that. I think you should not depend on users to upgrade just on the basis of a document, but imho you should guide them where you can by throwing exceptions or a least print big warnings when users try to use deprecated features. Make classes and methods that can't be extended anymore final. Stuff like that. I have no idea how well Tapestry does in this respect. Personally, I think there are more interesting things to look at than backwards compatibility. Skimming through the (nice looking) documents, I definitively get the impression that this is a much improved version. I think the fact that Howard and team keep looking for improvements and are bold enough to start over at the drawing board makes them good engineers. As far as I can tell however, Tapestry still is centered around static component trees and a declarative programming model. For UI building, I prefer an imperative model like is supported by GWT and Wicket, as that provides it's users with more freedom to use and extend the framework however they see fit, and it makes creating complex UIs (e.g. using introspection to build up panels, and swap in/ out panels like you'd do with wizards and stacks) easier. In the same fashion, I'm not super crazy about Flex 3's mxml either (though I don't hate it, and imho they made better choices than JSF). Flex mxml also provides a declarative model with some dynamic extensions (like states and viewstacks). And having it used side by side with Wicket for a few weeks (the project I work on uses both frameworks), my conclusion is that while it saves some of the plumbing code for straightforward components, code gets messier when trying to achieve more complex things. I expect this to be roughly the same for Tapestry, and I base that on the documentation I read and examples I've seen. Last few opinions: * I read that some people think T5 should have used Spring for IoC. I disagree; the IoC engine is probably more focussed on what T needs, and prevents the bloat and being dependent on the update schedule of 3rd party libs. Always nice however to at least give your users the chance to swap implementations if they want to. * Planned integration with Spring Web Flow... I wrote this http://chillenious.wordpress.com/2006/07/16/on-page-navigation/ two years ago, and still feel the same. :-) My 2c
  100. I seem to be going against the flow here, but I think it is fine that Tapestry has big API breaks between major releases.
    I agree. I'm not sure why the Tapestry project catches alot of flak for this... (then again, I'm not one of those that have been burned by these transitions). If you look at Tap 3, 4 and 5 as completely different frameworks that have evolved from the same basic concepts, then the compatibility breaks are justifiable. Just look at the difference between Struts and Struts2. Struts2 was obviously named to ride on the huge cache enjoyed by the Struts brand, even though it is a more direct descendant of Webwork than Struts. Tapestry 5 follows the same strategy, but in this case it seems to have backfired. Maybe Tapestry 5 would have been better received if it had been given a completely different name?
  101. BTW first I have to admit in general Tapestry is a decent framework, but like any other framework it has some weaknesses. The biggest complain I have with Tapestry (I don't know how much it is still true in Tapestry 5 ) is unlike the Widget based component frameworks (e.g. Wicket, Webforms etc), Tapestry supports template based components, which is not very helpful if you want to add components dynamically to your page. Of course you can spit any markup with IMarkupWriter, but this is not really a handy approach to generate dynamic components.
  102. JSF2 Composite Components[ Go to top ]

    Tapestry 5 looks interesting, but FWIW, composite components in JSF2 will not require *any* Java artifacts. Just a decoratable XML template.