em. My experience working with Tapestry and hivemind has not been a lack of documentation. What I found is that there is a play off between time spent on following an example and actually experimenting in code. If there were more documentation there would be a potential greater time sink since it is not possible to document every scenario. There are complex and confusing issues at first especially such as the choice between implicit, explicit XML and property injection of a component etc. Between Tapestry and Hivemind each requires its own way of working. With Hivemind I found I had to make frequent refence to the DTD. Not so with Tapestry. With Hivemind it is as well to bear in mind that you are pushing to a stack (order maybe significant) while ids direct flow between stanzas. There is little that can't be achieved with Hivemind if you build your own object translators, though getting too complex defeats the point. Our team has also not found a transition from T3.1 to T4.1(?) particularly painful. Tapestry lives up to its promise of modularisation of development, encouraging working on discrete tasks and allowing people to pass from task to task. Because of this it allows maintenance of code and folding in of changes. These are huge gains. I post separately on improving tapestry. Adam Saltiel
On 03/03/06, Jason Suplizio <[EMAIL PROTECTED]> wrote: > > 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] > > > > > > > > > > > > > > > > > >
