did u follow the tapestry quickstart in http://tapestry.apache.org/tapestry5.1/quickstart/ ? I don't think it could get easier than this. U can even run it inside eclipse if u have the m2 plugin for maven.
i do agree with u that the documentation could be better, however, reading your message somebody could believe that starting a new tapestry project is extremely difficult and it's totally the contrary. On Wed, Jun 17, 2009 at 7:21 PM, Norman Franke<nor...@myasd.com> wrote: > I've been using T4/4.1 for several years and have been quite pleased with > it. I've been using it with Hibernate, and while not perfect, it's worked > pretty well. We've found it much faster to embed a web browser in our main > app and do editing, queries and the like via Tapestry than writing native > code. > > I have a new project to replace our aging billing system. I figured this > would be a great way to learn T5. So, I'm migrating me, not an app. :-) > > I was pondering posting this, but this thread sort of pushed me over the > top. Note that I don't disagree with anything Howard said. However, this > almost became "Why I almost dumped Tapestry entirely." > > I'm writing this in order to solicit feedback and maybe help others. I've > been using Tomcat (now 6.0.20) and Eclipse (now 3.4.2) for quite time time, > and I'm very productive developing use them (and T4.1) I think this is a > pretty common development environment. > > To get started in T5 for a fresh new app, my first thought was to follow the > tutorial at http://tapestry.apache.org/tapestry5.1/tutorial1/. > > Chapter 2 just plain didn't work for me. I think part of it is due to Maven > generally being extremely fragile and working less than half of the time. > However, even after working around that, you can't just import the project > into Eclipse. At least not under Eclipse 3.4.2. > > No problem, I thought. Maven is annoying anyway. I'll just create a Dynamic > Web project (like I do for T4.1) and download the T5.1 binary distribution. > That's even worse. It comes with no README listing dependencies or anything > useful, and includes tons of libraries that don't appear to be even needed. > Tapestry failed to start up during initialization. Why have a binary distro > that doesn't work? > > Back to Maven. After some googling, I found this article: > http://tapestry.formos.com/wiki/display/T5IDEINT/Eclipse+(including+Maven) Shouldn't > this be included in the tutorial? Sadly, the tutorial is extremely basic, > but at least it works. (And is the only way I've found to actually create a > new project in Eclipse to date.) > > Next, I tried Tapestry Jumpstart. After hours of configuration and random > errors (using Tomcat), it worked. However, it's so fragile and klugy that I > just can't see using it in production. I don't care about OpenEJB. I want > just plain T5.1 and Hibernate. Plus running in a remote tomcat sessions > eliminates many of the developer productivity benefits of T5 in the first > place. One thing I liked about T4 was that I could deploy a WAR to a stock > Tomcat install, and it would just work. That won't happen with Jumpstart. > Plus. it if takes 3 hours to just get a working developer environment, why > even bother? > > Next up, AppFuse. It's only T4, but there is a Tapestry 5 add-on. Sadly, > AppFuse's T4 support is now broken due to a dependancy on tapestry-flash > that appears to be missing and following the instructions on the AppFuse > Tapestry 5 page doesn't work anymore either, resulting in tons of missing > resources. > > So, since T5 doesn't appear to provide much in the way of authentication / > security (a very basic requirement for almost all webapps), I started down > the tapestry5-acegi approach. Of course, that doesn't work with T5.1. I > managed to get it working and then upgraded to tapestry-spring-security > 2.1.0-SNAPSHOT. Still didn't work without augmentation. (Thanks to maven for > not updating the packages when I switched to the snapshot, too. I had to > delete the "nu" directory in my ~/.m2 directory. One more reason Maven > blows. It just doesn't do what you want.) > > I'd love to see more people use Tapestry, but after attempting a new > project, I'd feel embarrassed asking people to give Tapestry a look at this > point. Heck, I'm thinking maybe sticking with T4.1 is the way to go, despite > all the benefits of T5. But, I really do want to start in on T5 since I've > loved using T4 for the last few years, and it does seem to be a step > forward. > > I think its common to want to just get something working in order to get a > feel for the framework. Doing so in Tapestry, at least for me, has been a > waste of two days. I finally, on the third day, I have something that > appears to allow the tutorial to work with basic security. I'm not sure if > others have similar problems and just gave up without comment, making other > frameworks seem more popular? > > Norman Franke > Answering Service for Directors, Inc. > www.myasd.com > > > > On Jun 16, 2009, at 7:20 PM, Howard wrote: > >> I recently had an e-mail exchange with a Tapestry user; after >> congratulating me on creating Tapestry, he went on with the following >> observation on his organization: The company I work at unfortunately >> chose JSF for their big app. The reason was that Tapestry was "brittle" >> in the sense that, if one developer breaks something, on a page or a >> service, very often the whole site won't come up because the initial >> registry startup will fail. Or for example, if page A has a pagelink to >> page B, and page B is broken, then page A won't render. While I agree >> that we shouldn't ship unless the whole app is working, this is a >> thousands of pages big app with hundreds of mediocre (as in likely to >> break things) developers. They'd rather have 80% of the thing working >> than nothing at all. I never thought of this for my own projects, and >> haven't had the time to examine the truth of their claims. What's your >> take? >> I provided the following response: >> Early failures are absolutely, 100%, the only path towards code >> quality. You may have heard the phrase "no broken windows" (see "The >> Tipping Point" by Malcom Gladwell for more details) but the short form >> is that when errors go uncorrected (whether they are broken windows in >> an abandoned building, or broken code in an application) they tend to >> multiply quite rapidly. >> The things that will "break" a link from page A to page B are >> substantial problems such as invalid templates, references to unknown >> properties or components, or compile errors in the page B class ... >> things that no other developer should ever see when page B's developer >> is working and checking in code. That is, problems that should never be >> checked into trunk, but instead kept in a local workspace or a private >> branch. >> An organization that thinks that fail early is a problem is an >> organization that isn't prepared to develop a large application in any >> technology. The image I'm getting is one where there is no build >> server, no continuous integration, at best CVS for source code >> management (or possibly one of those "shared directory" >> monstrosities) .... i.e., a chaotic environment where errors are >> allowed to be checked in to the trunk and can go unnoticed for some >> time. >> The solution to coding errors in pages or components is not to wait >> until your testers (or end users) find the bugs, but to identify and >> fix the bugs early. That's called "engineering discipline" and the >> reality is that even self-professed "mediocre" developers can do it. >> Tapestry helps because it fails early and has great exception reporting >> to guide you right the problem so that you can fix it. >> Another factor here is enforced helplessness. If only Fred understands >> page B and he's out when it's broken, then all development stops >> waiting for Fred to get back. I hit this problem myself, years ago >> working on a large Struts application (those words give me the heebie >> jeebies now!). We had lots of code, a fragile and slow build process, >> and many little code "fiefdoms". I spent too much wasted time twiddling >> my thumbs. >> Nobody should "own the code"; if page B is is broken, Julie (who >> normally develops page A) should be free to fix it. Julie will need to >> understand the page B code well enough to fix it, but also you need an >> overall environment with shared source, no repository locks (that is, >> nothing that says "Only Fred can change this file"), and no management >> PHB's getting in the way. Pair programming is the best way for Fred and >> Julie to share knowledge so that they can understand each other's code. >> Even if pairing occurs only part time, it's very effective at knowledge >> transfer as well as ordinary coding. >> The idea that "mediocre" developers should use JSF as it is more >> tolerant of errors is absurd! Tapestry 5 is designed to improve >> productivity for all developers, by streamlining, simplifying, being >> smart and being concise ... not to mention live class reloading and >> best-of-breed exception reporting, which makes it fast to identify and >> fix those errors. >> If your doctor tells you to eat less red meat, that doesn't mean you >> should switch to a diet of fried chicken three meals a day! Likewise, >> if you have concerns with code quality from your developers, you should >> not switch to a less agile, more code-intensive, less supportive >> development model and hope to catch all the bugs in QA. Sweeping >> problems under the rug is never a winning strategy. >> Coming down off my soap box, I should also add that Tapestry 5.1 works >> a little bit differently than 5.0 in this respect, so it does (in fact) >> defer more of the page loading and validation until a link is actually >> clicked. This is more for performance reasons than to shield developers >> from application problems. Even in 5.0, the loading and validation was >> the "reach" from page A to pages explicitly referenced (usually via >> PageLink during the rendering of page A), so it's a highly unlikely >> case that a single error in a 1000 page application will keep the >> application from starting up, unless the start page of the application >> links to all 999 other pages. >> Re-reading the above post I can't emphasize enough: you can't ignore >> quality problems. Quality problems lead to development failures, >> schedule slips, missing functionality, low morale and high turnover. >> Saying "we don't have time to fix the quality problem first" is to >> ignore the the second law of Thermodynamics. You are expecting a >> miracle, literally writing it into your project plan. >> Formos addresses this issue two ways: First, we use Scrum and deliver >> on (typically) 4 week cycles. Thus we set real deadlines and have a >> constant check on quality (we're providing working code constantly). We >> don't even try to predict what we'll be doing six months or two years >> from now, we just deliver a steady, manageable stream of software. >> Secondly, Formos uses Tapestry because of all the reasons that the >> anonymous developer's organization rejected it, and for many, many more >> reasons besides. >> >> -- >> Posted By Howard to Tapestry Central at 6/16/2009 03:45:00 PM > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
