I'm in the middle of a comprehensive review for my employer of our team's Tapestry experience. Although much praise went to Kent, Howard, and for all the help from the committers/developers on this list (thank you), the lack of documentation was a common theme through the evaluation (esp. Hivemind) that prevents us from expanding our adoption into other applications.
But, hell, I worked on C#/VB .Net for the 2 years prior to this last year an lemme tell you, the MS documentation is horrible and often totally inaccurate. So, for not being the Sun or MS, the Tapestry team has an outstanding job and deserves serious kudos. The documentation short-comings, however, makes the learning curve feel infinitely steep. On 3/3/06, Peter Svensson <[EMAIL PROTECTED]> wrote: > > <agnostic>Amen!</agnostic> Could someone just for crying out loud at the > very least finish the api documentation with short examples on the main > site. > I would if I could but I can't so I won't. > > Sorry to be obnoxious. > > Cheers, > PS > > On 3/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > Last month, I generated numerous e-mails on this list about dynamic > > components. After a lot of hair pulling, because a lot of tooth > pulling, > > I finally figured out how to do the whole block/for/if/db > solution. Yes, > > this solution is pretty annoying; especially to a dev who is more > > concerned about getting his product out the door than adhering to a > design > > dogma. > > > > However, I think the tragic flaw is not in the difficulty of the > > block/for/if solution, but in its lack of documentation. It seems to be > > well understood by a few Tapestry gurus, but a complex secret to us lay > > folks. > > > > I believe that Tapestry would be best served not by rushing to fix bugs > in > > 4.0 or forge ahead to 4.1, but by providing exhaustive > documentation--the > > majority of which should be examples. We spend *so much* time working > > through Tapestry's unique behavior because we have very few points of > > reference from which to draw. Tapestry in Action is a decent > start. Kent > > Tong's book is a better start (IMHO). But there needs to be more > > information. More examples. We've almost completely shelved the idea > of > > going to 4.0 for a long time (we're coding in 3.0.3) because we believe > it > > needs to stabilize AND because there are fewer examples available than > > 3.0.3. Why fight that battle anew? > > > > I've come to appreciate Tapestry & have found a certain amount of > > efficiency to it, but only after a steep learning curve and plenty of > > frustration. Two examples: dynamic components and application catalogs. > > Dynamic components is possible, but there's no clear set of examples or > > documentation. Application catalogs are documented, but don't > work. The > > workaround is *brutal*, but possible....if you're willing to go it > alone. > > > > > > > > > > > > > > "Todd Orr" <[EMAIL PROTECTED]> > > 03/03/2006 08:45 AM > > Please respond to > > "Tapestry users" <tapestry-user@jakarta.apache.org> > > > > > > To > > "Tapestry users" <tapestry-user@jakarta.apache.org> > > cc > > > > Subject > > Re: How to improve Tapestry > > > > > > > > > > > > > > IMHO, the biggest feature that Tapestry is missing is solid dynamic > > component generation. Time and time again you'll see devs asking the > > same question in the forums, "how do I dynamically generate..." Each > > time someone points out the block, the for, or the if constructs. Yet > > these always seem way more difficult than they should be. Even with > > these tools, content management systems are notoriously difficult to > > build with Tapestry. Since Tapestry makes most things easier, this > > seems to be ironic. I began using Tapestry because most of my > > development time was cut in half, but the dynamic form development > > tasks I had to perform were tripled in time! Now, I could be the > > crappiest dev on earth, but I doubt it considering all the trouble > > everyone else has with this task and Tapestry. Because Tapestry is > > static, the very idea of dynamic components seems to leave a bad taste > > in Howard's mouth (and the mouths of die-hard enthusiasts). Yet it > > shouldn't, dynamic form generation is a very real, and fairly common > > task. It should be a first class citizen in the land of Tapestry. > > > > Just to make sure the tone of this post isn't misunderstood: I love > > Tapestry. Yet, everything can stand some measure of > > improvement/rethinking. > > > > On 3/3/06, Mark Stang <[EMAIL PROTECTED]> wrote: > > > > > > Look at http://www.nextapp.com (a.k.a. echo2). > > > > > > regards, > > > > > > Mark > > > > > > -----Original Message----- > > > From: Apache [mailto:[EMAIL PROTECTED] > > > Sent: Fri 3/3/2006 5:04 AM > > > To: tapestry-user@jakarta.apache.org > > > Subject: How to improve Tapestry > > > > > > I think Tapestry already makes a big step forward > > > but still there is a lot of things that could be made more dynamic and > > free programmers of templates and component definitions. > > > > > > In my opinion everything could be in the database instead of > > configuration files. > > > > > > In my idea world there should only be Java Classes > > > and no XML/Html/Page files. > > > > > > I only want to tell the system to "genrate a form with the fields I > tell > > you" and to tell it which fields are editable - the rest should be done > > automatically. Maybe you could tell how to order or align them, but I > dont > > want to write any html templates. > > > > > > > > > -------------------- m2f -------------------- > > > > > > Sent from www.TapestryForums.com > > > > > > Read this topic online here: <<topic_link>> > > > > > > http://www.tapestryforums.com/viewtopic.php?p=14479#14479 > > > > > > -------------------- m2f -------------------- > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > >
