> > if there were an exciting open source enterprise level web > application that is based on Tapestry (and also Spring), and which > could appeal to general public....
Would I be interested? Yes. About improving Tapestry. I hadn't researched into forms processing apps, although what I have just read here doesn't surprise me. It came my way to consider such a possibility, actually much like the original poster's comments. I wondered how this might be achieved in tapestry. The general form of development is to, somehow, take a schema and create an object model around it and then write Tapestry (or other framework) over it. This is often dictated by the customer. But it means that each class is made up of several fields, each with their own name, and attached to their own class, while the actual fields are nothing but a text field or what ever. In many circumstances it would be more useful to distinguish each field on the basis of what it does in its context, that is should the contents be taken in conjunction with other contents that have just been entered and if so, how? A unique name doesn't supply this information! But, and I note other posts on this list, semantic information would. So my thinking is that a way to forward Tapestry would be to enable semantic descriptions of objects and this would determine how they are processed.We should remember that Tapestry is not wedded to hibernate or what ever, it would be possible to have an intervening semantic layer and this could obviate some of the problems that exist in tapestry, or for this way of populating dbs. wrt Tapestry I wonder if this might be a way of attaching an id to an as yet to be rendered table within a table, I speculate? wrt dbs, might using OWL or RDF stores avoid the problem of fighting over field sizes that often happens when translating an XML schema into tables, again, I speculate? Anyway, thoughts, Best, Adam On 03/03/06, adasal <[EMAIL PROTECTED]> wrote: > > 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] > > > > > > > > > > > > > > > > > > > > > > > > > > >
