RE: T5: What is NOT beautiful about Tapestry?
Yup, its true the only problem of Tapestry 5. It lacks full documents that can help many newbies to learn this framework. As long as its FREE I will be a Tapestry lover... Not all things in this world is EASY! Newham, Cameron wrote: 3) Documentation - Good solid reference examples of how to do do simple apps, explained in detail. Most developers want a framework to be like lego building blocks. I do A, B, C and D and I get E. I assemble a dozen different pieces and I have my app. Really how complicated are most web apps? They are forms and workflow and validation. To get developers to use your framework you need good examples of how to do each, laid out and described in simple guaranteed to work steps. There need to be examples of these in both Netbeans and Eclipse; preferably several examples of each. --- All good points, but this above all others I think. Developers never seem to fully appreciate this - or if they do, they make it a lesser priority. Documentation is critical. It doesn't matter how good something is (and that those in the know know it), it's rendered useless if the documentation doesn't exist or is not up to scratch. Tapestry 5 documentation is not up to scratch. I'll repeat that: Tapestry 5 documentation is not up to scratch. Why? Unfortunately there are a plethora of places to look in if you want to find how to do something. It's not only annoying for people who are developing in Tapestry, it is off-putting to new developers who are looking at this as a possible solution to a development problem. We've now reached a stage in web development where things should be easy to put together (Lego building blocks). I used to hate web development and Tapestry 3 was the first thing I found which helped me dislike it a lot less. Tapestry 5 even more so. However, having no good set of central documentation, how-tos, cookbook solutions, etc makes the development process that much harder and not like Lego blocks. I really only want to have to think about business logic and know only the basics of how Tapestry works. Turning to the source code should be a last resort and I've had to do that once so far with Tapestry 5 because the documentation I required was inadequate (can't remember what it was now, but it wasn't even anything exotic I was trying to do!) That said, I think this mailing list is fantastic and has certainly ridden to my rescue on numerous occasions. The only off-putting thing is the fear of asking the dumb question. Sure, no questions are dumb, but I always feel a lot better if I know I've made an effort to find out how to do something before asking on here. Again, lack of good docs makes that effort so much harder and also increases the traffic on here by the same questions being asked multiple times. ** Experience the British Library online at www.bl.uk The British Library's new interactive Annual Report and Accounts 2007/08 : www.bl.uk/knowledge Help the British Library conserve the world's knowledge. Adopt a Book. www.bl.uk/adoptabook The Library's St Pancras site is WiFi - enabled * The information contained in this e-mail is confidential and may be legally privileged. It is intended for the addressee(s) only. If you are not the intended recipient, please delete this e-mail and notify the postmas...@bl.uk : The contents of this e-mail must not be disclosed or copied without the sender's consent. The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the British Library. The British Library does not take any responsibility for the views of the author. * - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- View this message in context: http://old.nabble.com/T5%3A-What-is-NOT-beautiful-about-Tapestry--tp23304774p26603363.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
RE: T5: What is NOT beautiful about Tapestry?
3) Documentation - Good solid reference examples of how to do do simple apps, explained in detail. Most developers want a framework to be like lego building blocks. I do A, B, C and D and I get E. I assemble a dozen different pieces and I have my app. Really how complicated are most web apps? They are forms and workflow and validation. To get developers to use your framework you need good examples of how to do each, laid out and described in simple guaranteed to work steps. There need to be examples of these in both Netbeans and Eclipse; preferably several examples of each. --- All good points, but this above all others I think. Developers never seem to fully appreciate this - or if they do, they make it a lesser priority. Documentation is critical. It doesn't matter how good something is (and that those in the know know it), it's rendered useless if the documentation doesn't exist or is not up to scratch. Tapestry 5 documentation is not up to scratch. I'll repeat that: Tapestry 5 documentation is not up to scratch. Why? Unfortunately there are a plethora of places to look in if you want to find how to do something. It's not only annoying for people who are developing in Tapestry, it is off-putting to new developers who are looking at this as a possible solution to a development problem. We've now reached a stage in web development where things should be easy to put together (Lego building blocks). I used to hate web development and Tapestry 3 was the first thing I found which helped me dislike it a lot less. Tapestry 5 even more so. However, having no good set of central documentation, how-tos, cookbook solutions, etc makes the development process that much harder and not like Lego blocks. I really only want to have to think about business logic and know only the basics of how Tapestry works. Turning to the source code should be a last resort and I've had to do that once so far with Tapestry 5 because the documentation I required was inadequate (can't remember what it was now, but it wasn't even anything exotic I was trying to do!) That said, I think this mailing list is fantastic and has certainly ridden to my rescue on numerous occasions. The only off-putting thing is the fear of asking the dumb question. Sure, no questions are dumb, but I always feel a lot better if I know I've made an effort to find out how to do something before asking on here. Again, lack of good docs makes that effort so much harder and also increases the traffic on here by the same questions being asked multiple times. ** Experience the British Library online at www.bl.uk The British Library's new interactive Annual Report and Accounts 2007/08 : www.bl.uk/knowledge Help the British Library conserve the world's knowledge. Adopt a Book. www.bl.uk/adoptabook The Library's St Pancras site is WiFi - enabled * The information contained in this e-mail is confidential and may be legally privileged. It is intended for the addressee(s) only. If you are not the intended recipient, please delete this e-mail and notify the postmas...@bl.uk : The contents of this e-mail must not be disclosed or copied without the sender's consent. The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the British Library. The British Library does not take any responsibility for the views of the author. * - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: What is NOT beautiful about Tapestry?
Em Fri, 01 May 2009 11:36:46 -0300, Tony Giaccone tgiacc...@gmail.com escreveu: That said, I'm not familiar at all with the changes in T5. However, the one thing that in the past has been a constant source of difficulty for everyone at my organization who's worked to learn Tapestry is the painful process of rewinding loops. Welcome to Tapestry 5, that has no rewinding phase! :) Yes, the rewiding in T4 was really hard to understand, so it was one of the first major differences between T4 and T5. -- Thiago H. de Paula Figueiredo Independent Java consultant, developer, and instructor http://www.arsmachina.com.br/thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: What is NOT beautiful about Tapestry?
alex, sorry you are right. I was blown away on points 2 4. 2009/5/1 kranga kra...@k2d2.org For Tap 3, we had a very elaborate form with loop implementation and we added Ajax-validation such that you only write validation code once in Java and for javascript validation, an ajax call is made to run the same validation code and bring back the results. The error handling could correctly handle n-input fields in a form all generated via a loop. Needless to say the code was quite complex and horrendously convoluted and now is outdated :( haha -- From: Inge Solvoll inge.tapes...@gmail.com Sent: Thursday, April 30, 2009 6:09 PM To: Tapestry users users@tapestry.apache.org Subject: Re: T5: What is NOT beautiful about Tapestry? Agree with Alex on the last comment about proving that issues don't exist! I have one example of a trivial thing that I have found difficult to implement in all Tapestry versions I have used(3, 4, 5): - A form with a loop in it. This is extremely common in the pages I make, and my mind always struggles when trying to find how this is done in the new Tapestry version. I never figured out a way to do it in 3 and 4 that made sense to me and looked correct. It also happened in T5. Maybe I'm stupid, but I really had to struggle hard to track down the details needed to implement this correctly, using encoders, initializing my form objects in the correct method in the correct way, and so on. I didn't find an example in the docs showing me the best practice for this (for me) very trivial and very common pattern. On Thu, Apr 30, 2009 at 11:17 PM, Alex Kotchnev akoch...@gmail.com wrote: I will echo Kranga's #1 and #2 and add a couple. I'm all for convention over configuration, but when you have to dig out the convention out of source code, mailing list, or somewhere else, I'd wish I had a well defined interface that I could just implement. The not-so-pojo aspect becomes too apparent when you have to write some test cases against the said components and you start scratching you head about now, how do I make all of those magical annotations work if I don't do the whole IoC bit where it will inject everything. One additional difficulty is that T5's model is so different in respect to AJAX that it takes a while to wrap (or warp) your head around what you need to do in order to do something seemingly simple w/ a known Javascript framework (e.g. think Dojo, Prototype, jQuery). There are a plethora of people out there that know how to make up a snazzy ajaxy interface; however, when it comes down to T5 you have to jump through a couple of hoops just to get the URL to which the Ajax code will hook into (e.g. the componentResources.createPageLink , createEventLink, etc). Componetization support and all within T5 is nice, but when you have to climb a big hill of learning a lot of T5 before you can do a silly autocompletion example for Dojo or jQuery, it just makes it harder than necessary. Certainly not a boon. Finally, it's great that T5 is so well decomposed into small interfaces , so that you can override anything you want. However, too many small classes/interfaces + a bunch of dependencies on each other (which are really easy to do when IoC can magically inject dependencies for you) starts being a drag when you want to implement/override one, and then you realize that in order to do one, you need to figure out a bunch more things that need to be injected (or something like that). It's really easy to get into a rabbit hole of oh, I wanted to implement this one thing, now I have to understand these other three before I can implement the first one Otho, I don't think the point of this thread is for us to prove that the issues that are brought up are not actually issues. The fact that people bring them up, means that those issues still exist. I doubt that someone will go through the trouble of typing up a big email regarding his troubles w/ T5 if these were not issues that he/she has dealt with. Cheers, Alex K On Thu, Apr 30, 2009 at 9:28 AM, kranga kra...@k2d2.org wrote: 1) Documentation: It is one thing to remove dependencies on framework interfaces but quite another to leave the developer hanging with no documentation. Programming by convention is programming in the dark if the convention is not known. 2) Although Tapestry claims to be POJO, you still have to have a contract (whether it is methods by convention or annotated methods). In the long run whether this is really better than interface implementation is not fully proven (much like the current debate of whether dynamically typed languages will prove more difficult to maintain in the long run). 3) Lack of a component marketplace: Wow, 4 years on and this is still on my list. We wrote a gigantic application in Tapestry 3 which is still in production. But we've decided to write all
Re: T5: What is NOT beautiful about Tapestry?
To possibly bring the discussion to a higher level: Why is T5 so far from being the DE FACTO STANDARD web framework? Is getting web developers to use T5 comparable to encouraging 80-year-olds to throw away their radio and use MP3 instead? The two actually seem related: - There's a learning curve (probably more intimidating seen from a distance) - There exists a strong standard that feels comfortable, familiar and somewhat sufficient - The supporters of the alternative are not your age, not your kind of people, and they don't hang where you hang. So who are we? Are we the new cool teenagers drawing the shape of the future, or are we the crazy religious people committing suicide together to try to get to the sacred planet? Inge On Fri, May 1, 2009 at 8:16 AM, Otho taa...@googlemail.com wrote: alex, sorry you are right. I was blown away on points 2 4. 2009/5/1 kranga kra...@k2d2.org For Tap 3, we had a very elaborate form with loop implementation and we added Ajax-validation such that you only write validation code once in Java and for javascript validation, an ajax call is made to run the same validation code and bring back the results. The error handling could correctly handle n-input fields in a form all generated via a loop. Needless to say the code was quite complex and horrendously convoluted and now is outdated :( haha -- From: Inge Solvoll inge.tapes...@gmail.com Sent: Thursday, April 30, 2009 6:09 PM To: Tapestry users users@tapestry.apache.org Subject: Re: T5: What is NOT beautiful about Tapestry? Agree with Alex on the last comment about proving that issues don't exist! I have one example of a trivial thing that I have found difficult to implement in all Tapestry versions I have used(3, 4, 5): - A form with a loop in it. This is extremely common in the pages I make, and my mind always struggles when trying to find how this is done in the new Tapestry version. I never figured out a way to do it in 3 and 4 that made sense to me and looked correct. It also happened in T5. Maybe I'm stupid, but I really had to struggle hard to track down the details needed to implement this correctly, using encoders, initializing my form objects in the correct method in the correct way, and so on. I didn't find an example in the docs showing me the best practice for this (for me) very trivial and very common pattern. On Thu, Apr 30, 2009 at 11:17 PM, Alex Kotchnev akoch...@gmail.com wrote: I will echo Kranga's #1 and #2 and add a couple. I'm all for convention over configuration, but when you have to dig out the convention out of source code, mailing list, or somewhere else, I'd wish I had a well defined interface that I could just implement. The not-so-pojo aspect becomes too apparent when you have to write some test cases against the said components and you start scratching you head about now, how do I make all of those magical annotations work if I don't do the whole IoC bit where it will inject everything. One additional difficulty is that T5's model is so different in respect to AJAX that it takes a while to wrap (or warp) your head around what you need to do in order to do something seemingly simple w/ a known Javascript framework (e.g. think Dojo, Prototype, jQuery). There are a plethora of people out there that know how to make up a snazzy ajaxy interface; however, when it comes down to T5 you have to jump through a couple of hoops just to get the URL to which the Ajax code will hook into (e.g. the componentResources.createPageLink , createEventLink, etc). Componetization support and all within T5 is nice, but when you have to climb a big hill of learning a lot of T5 before you can do a silly autocompletion example for Dojo or jQuery, it just makes it harder than necessary. Certainly not a boon. Finally, it's great that T5 is so well decomposed into small interfaces , so that you can override anything you want. However, too many small classes/interfaces + a bunch of dependencies on each other (which are really easy to do when IoC can magically inject dependencies for you) starts being a drag when you want to implement/override one, and then you realize that in order to do one, you need to figure out a bunch more things that need to be injected (or something like that). It's really easy to get into a rabbit hole of oh, I wanted to implement this one thing, now I have to understand these other three before I can implement the first one Otho, I don't think the point of this thread is for us to prove that the issues that are brought up are not actually issues. The fact that people bring them up, means that those issues still exist. I doubt that someone will go through the trouble of typing up a big email regarding his troubles w/ T5 if these were not issues that he/she has dealt
Re: T5: What is NOT beautiful about Tapestry?
is programming in the dark if the convention is not known. 2) Although Tapestry claims to be POJO, you still have to have a contract (whether it is methods by convention or annotated methods). In the long run whether this is really better than interface implementation is not fully proven (much like the current debate of whether dynamically typed languages will prove more difficult to maintain in the long run). 3) Lack of a component marketplace: Wow, 4 years on and this is still on my list. We wrote a gigantic application in Tapestry 3 which is still in production. But we've decided to write all new apps in JSF with the aim of quickly adopting 2.0 when the spec is released. The main reason - a plethora of components to choose from. 4) Developer mindshare: Our analysis with Tapestry 3 shows that for every developer we hire, we have to write off 2-4 weeks until they become well versed in Tapestry. I don't believe T5 will be any different. You cannot argue against a standard like JSF that is supported by vendors. The lack of penetration of JSF speaks to its terrible initial design which hopefully will be rectified in 2.0 I don't believe Tapestry will dwindle and die but I don't see it becoming the defacto standard ala Struts in the early 2000s. -- From: Pedro Januário prnjanua...@gmail.com Sent: Thursday, April 30, 2009 5:43 AM To: Tapestry users users@tapestry.apache.org Subject: Re: T5: What is NOT beautiful about Tapestry? I totally agree with Hugo's ideia. The wiki sounds good and should be a easy to make documentation about common problems. 2009/4/30 Hugo Palma hugo.m.pa...@gmail.com I agree a book would be great, what happened to the tapestry5-book project http://code.google.com/p/tapestry5-book/ ? Still, i think a lot better could be done with the online documentation. I believe the structure of the online documentation should be very similar to a book, it should start with the basics and evolve to more hardcore stuff from there. Just the fact that the current documentation is structured with only one level of depth and the list of item is ordered alphabetically makes the task of finding some information much more difficult. I for example really like how the hibernate documentation is structure, i usually have to problem finding what i'm looking for there. So, maybe the wiki could be a starting place for the birth of a documentation with such a structure. On Thu, Apr 30, 2009 at 10:06 AM, Blower, Andy andy.blo...@proquest.co.uk wrote: I think you hit the nail on the head Carl. The documentation is okay generally (some bits poor, some very good) but there is not enough to tie it all together and guide new developers so they know what they can do with T5. I'm not convinced that the main documentation should attempt this on its own, or whether it should strive to be a great reference with some more higher level introductory/discovery bits along with a good published book to handle introducing everything and tying it together. Having the only published book for T5 being so out of date is a huge problem for the framework in my opinion. I don't think a wiki is the answer to this, I really like knowing that the documentation that I'm looking at is for a specific version of Tapestry and is updated when the code is - I would not want to lose that. Andy. -Original Message- From: Carl Crowder [mailto:carl.crow...@taptu.com] Sent: 29 April 2009 22:04 To: Tapestry users Subject: Re: T5: What is NOT beautiful about Tapestry? Discovery of it's parts. Franky the documentation is lacking and even with reading the mailing list, reading the howtos wiki, buying the Tapestry 5 book and working with it for over a year I still come across things I never knew existed that would have solved a problem I've had. I often spend ages writing something myself after searching for a solution. What's beautiful about Tapestry? That almost every problem has a simple solution built in. What's not beautiful about Tapestry? That I generally find these solutions by accident, and way after I've written my own! Lots of things are obvious and easy to understand once you know what they are but it's learning what they are that is the problem. I've been waxing lyrical about Tapestry where I work and while the developers who tried it love it, their main gripe is always that it's difficult to understand what it can do. The cookbook is the right idea but it's only got 5 entries right now. It needs to be way more comprehensive Inge Solvoll wrote: Hi! I have been reading
Re: T5: What is NOT beautiful about Tapestry?
once in Java and for javascript validation, an ajax call is made to run the same validation code and bring back the results. The error handling could correctly handle n-input fields in a form all generated via a loop. Needless to say the code was quite complex and horrendously convoluted and now is outdated :( haha -- From: Inge Solvoll inge.tapes...@gmail.com Sent: Thursday, April 30, 2009 6:09 PM To: Tapestry users users@tapestry.apache.org Subject: Re: T5: What is NOT beautiful about Tapestry? Agree with Alex on the last comment about proving that issues don't exist! I have one example of a trivial thing that I have found difficult to implement in all Tapestry versions I have used(3, 4, 5): - A form with a loop in it. This is extremely common in the pages I make, and my mind always struggles when trying to find how this is done in the new Tapestry version. I never figured out a way to do it in 3 and 4 that made sense to me and looked correct. It also happened in T5. Maybe I'm stupid, but I really had to struggle hard to track down the details needed to implement this correctly, using encoders, initializing my form objects in the correct method in the correct way, and so on. I didn't find an example in the docs showing me the best practice for this (for me) very trivial and very common pattern. On Thu, Apr 30, 2009 at 11:17 PM, Alex Kotchnev akoch...@gmail.com wrote: I will echo Kranga's #1 and #2 and add a couple. I'm all for convention over configuration, but when you have to dig out the convention out of source code, mailing list, or somewhere else, I'd wish I had a well defined interface that I could just implement. The not-so-pojo aspect becomes too apparent when you have to write some test cases against the said components and you start scratching you head about now, how do I make all of those magical annotations work if I don't do the whole IoC bit where it will inject everything. One additional difficulty is that T5's model is so different in respect to AJAX that it takes a while to wrap (or warp) your head around what you need to do in order to do something seemingly simple w/ a known Javascript framework (e.g. think Dojo, Prototype, jQuery). There are a plethora of people out there that know how to make up a snazzy ajaxy interface; however, when it comes down to T5 you have to jump through a couple of hoops just to get the URL to which the Ajax code will hook into (e.g. the componentResources.createPageLink , createEventLink, etc). Componetization support and all within T5 is nice, but when you have to climb a big hill of learning a lot of T5 before you can do a silly autocompletion example for Dojo or jQuery, it just makes it harder than necessary. Certainly not a boon. Finally, it's great that T5 is so well decomposed into small interfaces , so that you can override anything you want. However, too many small classes/interfaces + a bunch of dependencies on each other (which are really easy to do when IoC can magically inject dependencies for you) starts being a drag when you want to implement/override one, and then you realize that in order to do one, you need to figure out a bunch more things that need to be injected (or something like that). It's really easy to get into a rabbit hole of oh, I wanted to implement this one thing, now I have to understand these other three before I can implement the first one Otho, I don't think the point of this thread is for us to prove that the issues that are brought up are not actually issues. The fact that people bring them up, means that those issues still exist. I doubt that someone will go through the trouble of typing up a big email regarding his troubles w/ T5 if these were not issues that he/she has dealt with. Cheers, Alex K On Thu, Apr 30, 2009 at 9:28 AM, kranga kra...@k2d2.org wrote: 1) Documentation: It is one thing to remove dependencies on framework interfaces but quite another to leave the developer hanging with no documentation. Programming by convention is programming in the dark if the convention is not known. 2) Although Tapestry claims to be POJO, you still have to have a contract (whether it is methods by convention or annotated methods). In the long run whether this is really better than interface implementation is not fully proven (much like the current debate of whether dynamically typed languages will prove more difficult to maintain in the long run). 3) Lack of a component marketplace: Wow, 4 years on and this is still on my list. We wrote a gigantic application in Tapestry 3 which is still in production. But we've decided to write all new
Re: T5: What is NOT beautiful about Tapestry?
On Fri, May 1, 2009 at 8:01 AM, Tony Giaccone tgiacc...@gmail.com wrote: I'll give my opinion on this, and I think I can speak with some authority as I used to work in WebObjects which at the time was by far head and shoulders above the rest of the pack of web development frameworks. In fact I would say that WebObject still in many ways leads the pack of Frameworks and it's pretty much been stagnant for the last 5 years. In addition while I've not worked with T5 yet, I have done work in both T3 and T4. I hope you get a chance to use T5 soon; it's the same flavor as T4, but a whole new recipe ... the differences are more than the sum of the deltas. 1) Tapestry has a deserved reputation for being a framework who's foundation is on shifting sands. The changes from T3 to T4, and then from T4 to T5 have been enormous. In the enterprise world, that's a major disadvantage. That the code is not backwards compliant, means that for an enterprise to stick with T5 it has to either continue on a framework that's become stagnant, or worse dead. Or invest a large amount of money re-writing an app to support a new architecture. I'll accept the shifting sands from Tx upto T4. One of the reasons I'm very interested in getting T5.1 out the door is to demonstrate my contention that T5's new architecture supports adding significant new features (i.e., performance boosts, better templates, gzip compression, javascript aggregation) without breaking backwards compatibility. 2) Hivemind - Learning Tapestry for many developers was an uphill battle. Understanding Hivemind and how to make use of it, was more like Mt Everest. Documentation was miserable, examples sparse. I was able to get the Hivemind to spin up services and work with Spring but boy it wasn't easy. Hivemind is gone in T5? The IOC container has to be well understood, well described, and documented with examples at the same level as Tapestry rendering frameworks. I think the new IoC container is much easier to understand, and there's no XML. People still stumble over the concept of service configurations. However, there's a lot more examples now, in the cookbooks and elsewhere. 3) Documentation - Good solid reference examples of how to do do simple apps, explained in detail. Most developers want a framework to be like lego building blocks. I do A, B, C and D and I get E. I assemble a dozen different pieces and I have my app. Really how complicated are most web apps? They are forms and workflow and validation. To get developers to use your framework you need good examples of how to do each, laid out and described in simple guaranteed to work steps. There need to be examples of these in both Netbeans and Eclipse; preferably several examples of each. Are you willing to fund this kind of effort? Didn't think so. Documentation is *hard*. I think Tapestry should get some kudos that the documentation is at least accurate. There's a wealth of very rich JavaDoc, the component reference, and lots of hand-tooled reference documentation. Nobody likes to do documentation. That's a problem in a volunteer effort. If Tapestry's committers reported to me, I'd be parceling out the kind of documentation you're talking about. That's not how it works. In a separate thread, I'm promoting the use of a wiki as the basis of future documentation. I think opening up documentation to the community is the only way of bridging the gap ... but that brings in its own problems w.r.t. oversight and accuracy (not to mention readability and consistency). 4) Stability - you need to lay down a road map that shows management and developers that they can count on a stable environment for the foreseeable future. Howard, T6 can't be so different from T5 that you have to rewrite apps. Tapestry has a bad reputation and if you want general adoption, you personally have to assure everyone that the days of major changes in the framework have ended. Now you are citing yourself as a newbie. Anyone who's followed this mailing list has seen Tapestry 6 come up and everyone, including myself, strike it down. Sure, there's a couple of things that I'd do differently now, but not enough to address the kind of effort involved in yet another rewrite. Again, 5.1 is a demonstration of the future path, where new features can be added non-disruptively. My personal opinion is that those four things are the starting point. They may not be enough, but if you can't get them done, you won't get anywhere in terms of major commercial adoption. WebObjects had most of those advantages and a few others ( an integrated object relational management system that blows away Hibernate for example), but it got killed because it wasn't Standards compliant. However, the truth is no one was willing to trust Apple, to provide them with a web development framework. They used the Standards compliant argument to discard what they really didn't want in the first place. If
Re: T5: What is NOT beautiful about Tapestry?
Nobody likes to do documentation. That's a problem in a volunteer effort. If Tapestry's committers reported to me, I'd be parceling out the kind of documentation you're talking about. That's not how it works. Why don't you create JIRA issues for those documenation tasks? This would show that documentation is as important as improvements/bugfixes and enhances Tapestrys overall quality. This could also lead to the community being able to contribute something to the framework. I for one like to pick myself some simple issue like localizing message catalogs or improving documentation and contribute and I could imagine that others might do the same. Uli - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: What is NOT beautiful about Tapestry?
The documentation point is often raised and of course it is never enough documentation and a book like writing that guides carefully through tapestry would be really great. However I think that the available documentation is still very, very good. Most of the things I need to know I find in the regular docs. If that doesn't help the javadocs are extremely helpful. There aren't that many open source projects that have such a decent documentation. I have to confess that I sometimes have to browse a couple of pages before I find the information. Maybe an integrated search in the site would help On Fri, May 1, 2009 at 7:39 PM, Ulrich Stärk u...@spielviel.de wrote: Nobody likes to do documentation. That's a problem in a volunteer effort. If Tapestry's committers reported to me, I'd be parceling out the kind of documentation you're talking about. That's not how it works. Why don't you create JIRA issues for those documenation tasks? This would show that documentation is as important as improvements/bugfixes and enhances Tapestrys overall quality. This could also lead to the community being able to contribute something to the framework. I for one like to pick myself some simple issue like localizing message catalogs or improving documentation and contribute and I could imagine that others might do the same. Uli - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: What is NOT beautiful about Tapestry?
I agree a book would be great, what happened to the tapestry5-book project http://code.google.com/p/tapestry5-book/ ? Still, i think a lot better could be done with the online documentation. I believe the structure of the online documentation should be very similar to a book, it should start with the basics and evolve to more hardcore stuff from there. Just the fact that the current documentation is structured with only one level of depth and the list of item is ordered alphabetically makes the task of finding some information much more difficult. I for example really like how the hibernate documentation is structure, i usually have to problem finding what i'm looking for there. So, maybe the wiki could be a starting place for the birth of a documentation with such a structure. On Thu, Apr 30, 2009 at 10:06 AM, Blower, Andy andy.blo...@proquest.co.uk wrote: I think you hit the nail on the head Carl. The documentation is okay generally (some bits poor, some very good) but there is not enough to tie it all together and guide new developers so they know what they can do with T5. I'm not convinced that the main documentation should attempt this on its own, or whether it should strive to be a great reference with some more higher level introductory/discovery bits along with a good published book to handle introducing everything and tying it together. Having the only published book for T5 being so out of date is a huge problem for the framework in my opinion. I don't think a wiki is the answer to this, I really like knowing that the documentation that I'm looking at is for a specific version of Tapestry and is updated when the code is - I would not want to lose that. Andy. -Original Message- From: Carl Crowder [mailto:carl.crow...@taptu.com] Sent: 29 April 2009 22:04 To: Tapestry users Subject: Re: T5: What is NOT beautiful about Tapestry? Discovery of it's parts. Franky the documentation is lacking and even with reading the mailing list, reading the howtos wiki, buying the Tapestry 5 book and working with it for over a year I still come across things I never knew existed that would have solved a problem I've had. I often spend ages writing something myself after searching for a solution. What's beautiful about Tapestry? That almost every problem has a simple solution built in. What's not beautiful about Tapestry? That I generally find these solutions by accident, and way after I've written my own! Lots of things are obvious and easy to understand once you know what they are but it's learning what they are that is the problem. I've been waxing lyrical about Tapestry where I work and while the developers who tried it love it, their main gripe is always that it's difficult to understand what it can do. The cookbook is the right idea but it's only got 5 entries right now. It needs to be way more comprehensive Inge Solvoll wrote: Hi! I have been reading the beautiful thread and added my opinion about what's great about Tapestry. It's nice to sum up why we all are so excited about this, it obviously makes both us and the creator(s) feel good about ourselves. But for a little while, I challenge us all to stop tapping each others' backs and go into depth about what's not to like about our beloved framework. The most obvious questions that could be asked probably have some very obvious answers. But T5, as I see it, is all about addressing stuff that other frameworks have given up on and create excellent implementations rather than just looking the other way. Difficult and uncomfortable questions should be addressed the same way. So: What are the main reasons that T5 isn't one of the big ones, when we all seem to agree that it is so much better than most other frameworks out there? Why is T5 NOT beautiful? Hope I'm not insulting anyone, I'm a big fan too, I just think this actually could lead to significant insight :) Regards Inge - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: What is NOT beautiful about Tapestry?
I totally agree with Hugo's ideia. The wiki sounds good and should be a easy to make documentation about common problems. 2009/4/30 Hugo Palma hugo.m.pa...@gmail.com I agree a book would be great, what happened to the tapestry5-book project http://code.google.com/p/tapestry5-book/ ? Still, i think a lot better could be done with the online documentation. I believe the structure of the online documentation should be very similar to a book, it should start with the basics and evolve to more hardcore stuff from there. Just the fact that the current documentation is structured with only one level of depth and the list of item is ordered alphabetically makes the task of finding some information much more difficult. I for example really like how the hibernate documentation is structure, i usually have to problem finding what i'm looking for there. So, maybe the wiki could be a starting place for the birth of a documentation with such a structure. On Thu, Apr 30, 2009 at 10:06 AM, Blower, Andy andy.blo...@proquest.co.uk wrote: I think you hit the nail on the head Carl. The documentation is okay generally (some bits poor, some very good) but there is not enough to tie it all together and guide new developers so they know what they can do with T5. I'm not convinced that the main documentation should attempt this on its own, or whether it should strive to be a great reference with some more higher level introductory/discovery bits along with a good published book to handle introducing everything and tying it together. Having the only published book for T5 being so out of date is a huge problem for the framework in my opinion. I don't think a wiki is the answer to this, I really like knowing that the documentation that I'm looking at is for a specific version of Tapestry and is updated when the code is - I would not want to lose that. Andy. -Original Message- From: Carl Crowder [mailto:carl.crow...@taptu.com] Sent: 29 April 2009 22:04 To: Tapestry users Subject: Re: T5: What is NOT beautiful about Tapestry? Discovery of it's parts. Franky the documentation is lacking and even with reading the mailing list, reading the howtos wiki, buying the Tapestry 5 book and working with it for over a year I still come across things I never knew existed that would have solved a problem I've had. I often spend ages writing something myself after searching for a solution. What's beautiful about Tapestry? That almost every problem has a simple solution built in. What's not beautiful about Tapestry? That I generally find these solutions by accident, and way after I've written my own! Lots of things are obvious and easy to understand once you know what they are but it's learning what they are that is the problem. I've been waxing lyrical about Tapestry where I work and while the developers who tried it love it, their main gripe is always that it's difficult to understand what it can do. The cookbook is the right idea but it's only got 5 entries right now. It needs to be way more comprehensive Inge Solvoll wrote: Hi! I have been reading the beautiful thread and added my opinion about what's great about Tapestry. It's nice to sum up why we all are so excited about this, it obviously makes both us and the creator(s) feel good about ourselves. But for a little while, I challenge us all to stop tapping each others' backs and go into depth about what's not to like about our beloved framework. The most obvious questions that could be asked probably have some very obvious answers. But T5, as I see it, is all about addressing stuff that other frameworks have given up on and create excellent implementations rather than just looking the other way. Difficult and uncomfortable questions should be addressed the same way. So: What are the main reasons that T5 isn't one of the big ones, when we all seem to agree that it is so much better than most other frameworks out there? Why is T5 NOT beautiful? Hope I'm not insulting anyone, I'm a big fan too, I just think this actually could lead to significant insight :) Regards Inge - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Cumprimentos... Pedro Januário
Re: T5: What is NOT beautiful about Tapestry?
As someone that usually tries to sell the idea of using Tapestry to others the main resistance points have been: - People love dragdrop and autocompletion :o) . It's a major letdown when i tell people they won't have any IDE integration with this framework. - The backwards compatibility thingy always comes into play. I always explain that with T5 that shouldn't be a problem but people always make the yeah right, that's what you said about T4. I guess this one will work itself out in time. As a developer: - The eternal documentation problem. - Support for AJAX is still very limited compared to the huge potential here. - No one works issues out except Howard. At least my experience as an issue creator is that the only developer to ever pick up on the issues i created and resolve them is Howard except some 1 or 2 cases. This obviously leads to longer times in issue resolution. Also, this leads back to the one man show problem tapestry has had although i feel that it's much better than a few years ago. I guess what i'm trying to say is that it's about time the other developers have a more active role on the development of the framework. On Wed, Apr 29, 2009 at 9:19 PM, Inge Solvoll inge.tapes...@gmail.com wrote: Hi! I have been reading the beautiful thread and added my opinion about what's great about Tapestry. It's nice to sum up why we all are so excited about this, it obviously makes both us and the creator(s) feel good about ourselves. But for a little while, I challenge us all to stop tapping each others' backs and go into depth about what's not to like about our beloved framework. The most obvious questions that could be asked probably have some very obvious answers. But T5, as I see it, is all about addressing stuff that other frameworks have given up on and create excellent implementations rather than just looking the other way. Difficult and uncomfortable questions should be addressed the same way. So: What are the main reasons that T5 isn't one of the big ones, when we all seem to agree that it is so much better than most other frameworks out there? Why is T5 NOT beautiful? Hope I'm not insulting anyone, I'm a big fan too, I just think this actually could lead to significant insight :) Regards Inge - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
RE: T5: What is NOT beautiful about Tapestry?
I think you hit the nail on the head Carl. The documentation is okay generally (some bits poor, some very good) but there is not enough to tie it all together and guide new developers so they know what they can do with T5. I'm not convinced that the main documentation should attempt this on its own, or whether it should strive to be a great reference with some more higher level introductory/discovery bits along with a good published book to handle introducing everything and tying it together. Having the only published book for T5 being so out of date is a huge problem for the framework in my opinion. I don't think a wiki is the answer to this, I really like knowing that the documentation that I'm looking at is for a specific version of Tapestry and is updated when the code is - I would not want to lose that. Andy. -Original Message- From: Carl Crowder [mailto:carl.crow...@taptu.com] Sent: 29 April 2009 22:04 To: Tapestry users Subject: Re: T5: What is NOT beautiful about Tapestry? Discovery of it's parts. Franky the documentation is lacking and even with reading the mailing list, reading the howtos wiki, buying the Tapestry 5 book and working with it for over a year I still come across things I never knew existed that would have solved a problem I've had. I often spend ages writing something myself after searching for a solution. What's beautiful about Tapestry? That almost every problem has a simple solution built in. What's not beautiful about Tapestry? That I generally find these solutions by accident, and way after I've written my own! Lots of things are obvious and easy to understand once you know what they are but it's learning what they are that is the problem. I've been waxing lyrical about Tapestry where I work and while the developers who tried it love it, their main gripe is always that it's difficult to understand what it can do. The cookbook is the right idea but it's only got 5 entries right now. It needs to be way more comprehensive Inge Solvoll wrote: Hi! I have been reading the beautiful thread and added my opinion about what's great about Tapestry. It's nice to sum up why we all are so excited about this, it obviously makes both us and the creator(s) feel good about ourselves. But for a little while, I challenge us all to stop tapping each others' backs and go into depth about what's not to like about our beloved framework. The most obvious questions that could be asked probably have some very obvious answers. But T5, as I see it, is all about addressing stuff that other frameworks have given up on and create excellent implementations rather than just looking the other way. Difficult and uncomfortable questions should be addressed the same way. So: What are the main reasons that T5 isn't one of the big ones, when we all seem to agree that it is so much better than most other frameworks out there? Why is T5 NOT beautiful? Hope I'm not insulting anyone, I'm a big fan too, I just think this actually could lead to significant insight :) Regards Inge - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: What is NOT beautiful about Tapestry?
1) Documentation: It is one thing to remove dependencies on framework interfaces but quite another to leave the developer hanging with no documentation. Programming by convention is programming in the dark if the convention is not known. 2) Although Tapestry claims to be POJO, you still have to have a contract (whether it is methods by convention or annotated methods). In the long run whether this is really better than interface implementation is not fully proven (much like the current debate of whether dynamically typed languages will prove more difficult to maintain in the long run). 3) Lack of a component marketplace: Wow, 4 years on and this is still on my list. We wrote a gigantic application in Tapestry 3 which is still in production. But we've decided to write all new apps in JSF with the aim of quickly adopting 2.0 when the spec is released. The main reason - a plethora of components to choose from. 4) Developer mindshare: Our analysis with Tapestry 3 shows that for every developer we hire, we have to write off 2-4 weeks until they become well versed in Tapestry. I don't believe T5 will be any different. You cannot argue against a standard like JSF that is supported by vendors. The lack of penetration of JSF speaks to its terrible initial design which hopefully will be rectified in 2.0 I don't believe Tapestry will dwindle and die but I don't see it becoming the defacto standard ala Struts in the early 2000s. -- From: Pedro Januário prnjanua...@gmail.com Sent: Thursday, April 30, 2009 5:43 AM To: Tapestry users users@tapestry.apache.org Subject: Re: T5: What is NOT beautiful about Tapestry? I totally agree with Hugo's ideia. The wiki sounds good and should be a easy to make documentation about common problems. 2009/4/30 Hugo Palma hugo.m.pa...@gmail.com I agree a book would be great, what happened to the tapestry5-book project http://code.google.com/p/tapestry5-book/ ? Still, i think a lot better could be done with the online documentation. I believe the structure of the online documentation should be very similar to a book, it should start with the basics and evolve to more hardcore stuff from there. Just the fact that the current documentation is structured with only one level of depth and the list of item is ordered alphabetically makes the task of finding some information much more difficult. I for example really like how the hibernate documentation is structure, i usually have to problem finding what i'm looking for there. So, maybe the wiki could be a starting place for the birth of a documentation with such a structure. On Thu, Apr 30, 2009 at 10:06 AM, Blower, Andy andy.blo...@proquest.co.uk wrote: I think you hit the nail on the head Carl. The documentation is okay generally (some bits poor, some very good) but there is not enough to tie it all together and guide new developers so they know what they can do with T5. I'm not convinced that the main documentation should attempt this on its own, or whether it should strive to be a great reference with some more higher level introductory/discovery bits along with a good published book to handle introducing everything and tying it together. Having the only published book for T5 being so out of date is a huge problem for the framework in my opinion. I don't think a wiki is the answer to this, I really like knowing that the documentation that I'm looking at is for a specific version of Tapestry and is updated when the code is - I would not want to lose that. Andy. -Original Message- From: Carl Crowder [mailto:carl.crow...@taptu.com] Sent: 29 April 2009 22:04 To: Tapestry users Subject: Re: T5: What is NOT beautiful about Tapestry? Discovery of it's parts. Franky the documentation is lacking and even with reading the mailing list, reading the howtos wiki, buying the Tapestry 5 book and working with it for over a year I still come across things I never knew existed that would have solved a problem I've had. I often spend ages writing something myself after searching for a solution. What's beautiful about Tapestry? That almost every problem has a simple solution built in. What's not beautiful about Tapestry? That I generally find these solutions by accident, and way after I've written my own! Lots of things are obvious and easy to understand once you know what they are but it's learning what they are that is the problem. I've been waxing lyrical about Tapestry where I work and while the developers who tried it love it, their main gripe is always that it's difficult to understand what it can do. The cookbook is the right idea but it's only got 5 entries right now. It needs to be way more comprehensive Inge Solvoll wrote: Hi! I have been reading the beautiful thread and added my opinion about what's great about Tapestry. It's nice to sum up why we all are so excited about this, it obviously makes
Re: T5: What is NOT beautiful about Tapestry?
Some interesting points here. 2009/4/30 kranga kra...@k2d2.org 1) Documentation: It is one thing to remove dependencies on framework interfaces but quite another to leave the developer hanging with no documentation. Programming by convention is programming in the dark if the convention is not known. Yes. That is the main time-eater. Finding out how non-trivial things are supposed to work. But that is a feature of most OS project's documentation: a) hello world b) some simplistic blog/calendar/whatever without any relevance to real world projects c) bits and pieces all over the net. And this is already good documentation as far as OS goes... The main problem here is that non comitters probably cannot help in writing the docs, since they just don't know enough. The result would not be better as what is there. One example of an excellent documentation in OS projects was Stripes Framework original docs by Tim Fennel. Since I didn't check the project for a long time I don't know about its current state. 2) Although Tapestry claims to be POJO, you still have to have a contract (whether it is methods by convention or annotated methods). In the long run whether this is really better than interface implementation is not fully proven (much like the current debate of whether dynamically typed languages will prove more difficult to maintain in the long run). There is no debate. One just has to look at the sources of well known and big scripted projects and the difficulties they have to maintain them. In the end there is no difference between the ugly php hacks and the more recent varieties of languages. If it is easy to program bad, then it will be done. Especially under time pressure. Statically typed languages make a lot of the more annoying mistakes hard to do, like typos which are only caught at runtime or wrong assignments like assigning a char sequence to a variable which is meant to be int and calculated upon. again only caught at runtime. Not having to implement an interface makes it easier for tapestry to change implicit contracts. That is a totally different beast when talking about interfaces with methods. But if it would be only marker interfaces there is anyways no difference between a certain package requirement or implementing an interface, so no reason to change anything. 3) Lack of a component marketplace: Wow, 4 years on and this is still on my list. We wrote a gigantic application in Tapestry 3 which is still in production. But we've decided to write all new apps in JSF with the aim of quickly adopting 2.0 when the spec is released. The main reason - a plethora of components to choose from. True. But since components are easy to make in Tapestry the market would probably be very limited anyways. All the important building parts are already there and for 95% of cases you get along with not more code than it would need to adapt to a premade component. JSF components are shiny and all, but they all require you to adapt to their needs while in Tapestry you can tailor components for your specific needs with relatively low effort. That said, some more premades would be nice :) 4) Developer mindshare: Our analysis with Tapestry 3 shows that for every developer we hire, we have to write off 2-4 weeks until they become well versed in Tapestry. I don't believe T5 will be any different. You cannot argue against a standard like JSF that is supported by vendors. The lack of penetration of JSF speaks to its terrible initial design which hopefully will be rectified in 2.0 I don't believe Tapestry will dwindle and die but I don't see it becoming the defacto standard ala Struts in the early 2000s. Yes, JSF gets all the hype because it is a standard. But reading in Java magazines makes it clear very fast, that even simple problems have quite complicated solutions. It is an endless well of articles for the mags and so the visibility even rises _because_ it is terribly designed. And a standard. And because it has shiny components with slick buttons.
Re: T5: What is NOT beautiful about Tapestry?
I will echo Kranga's #1 and #2 and add a couple. I'm all for convention over configuration, but when you have to dig out the convention out of source code, mailing list, or somewhere else, I'd wish I had a well defined interface that I could just implement. The not-so-pojo aspect becomes too apparent when you have to write some test cases against the said components and you start scratching you head about now, how do I make all of those magical annotations work if I don't do the whole IoC bit where it will inject everything. One additional difficulty is that T5's model is so different in respect to AJAX that it takes a while to wrap (or warp) your head around what you need to do in order to do something seemingly simple w/ a known Javascript framework (e.g. think Dojo, Prototype, jQuery). There are a plethora of people out there that know how to make up a snazzy ajaxy interface; however, when it comes down to T5 you have to jump through a couple of hoops just to get the URL to which the Ajax code will hook into (e.g. the componentResources.createPageLink , createEventLink, etc). Componetization support and all within T5 is nice, but when you have to climb a big hill of learning a lot of T5 before you can do a silly autocompletion example for Dojo or jQuery, it just makes it harder than necessary. Certainly not a boon. Finally, it's great that T5 is so well decomposed into small interfaces , so that you can override anything you want. However, too many small classes/interfaces + a bunch of dependencies on each other (which are really easy to do when IoC can magically inject dependencies for you) starts being a drag when you want to implement/override one, and then you realize that in order to do one, you need to figure out a bunch more things that need to be injected (or something like that). It's really easy to get into a rabbit hole of oh, I wanted to implement this one thing, now I have to understand these other three before I can implement the first one Otho, I don't think the point of this thread is for us to prove that the issues that are brought up are not actually issues. The fact that people bring them up, means that those issues still exist. I doubt that someone will go through the trouble of typing up a big email regarding his troubles w/ T5 if these were not issues that he/she has dealt with. Cheers, Alex K On Thu, Apr 30, 2009 at 9:28 AM, kranga kra...@k2d2.org wrote: 1) Documentation: It is one thing to remove dependencies on framework interfaces but quite another to leave the developer hanging with no documentation. Programming by convention is programming in the dark if the convention is not known. 2) Although Tapestry claims to be POJO, you still have to have a contract (whether it is methods by convention or annotated methods). In the long run whether this is really better than interface implementation is not fully proven (much like the current debate of whether dynamically typed languages will prove more difficult to maintain in the long run). 3) Lack of a component marketplace: Wow, 4 years on and this is still on my list. We wrote a gigantic application in Tapestry 3 which is still in production. But we've decided to write all new apps in JSF with the aim of quickly adopting 2.0 when the spec is released. The main reason - a plethora of components to choose from. 4) Developer mindshare: Our analysis with Tapestry 3 shows that for every developer we hire, we have to write off 2-4 weeks until they become well versed in Tapestry. I don't believe T5 will be any different. You cannot argue against a standard like JSF that is supported by vendors. The lack of penetration of JSF speaks to its terrible initial design which hopefully will be rectified in 2.0 I don't believe Tapestry will dwindle and die but I don't see it becoming the defacto standard ala Struts in the early 2000s. -- From: Pedro Januário prnjanua...@gmail.com Sent: Thursday, April 30, 2009 5:43 AM To: Tapestry users users@tapestry.apache.org Subject: Re: T5: What is NOT beautiful about Tapestry? I totally agree with Hugo's ideia. The wiki sounds good and should be a easy to make documentation about common problems. 2009/4/30 Hugo Palma hugo.m.pa...@gmail.com I agree a book would be great, what happened to the tapestry5-book project http://code.google.com/p/tapestry5-book/ ? Still, i think a lot better could be done with the online documentation. I believe the structure of the online documentation should be very similar to a book, it should start with the basics and evolve to more hardcore stuff from there. Just the fact that the current documentation is structured with only one level of depth and the list of item is ordered alphabetically makes the task of finding some information much more difficult. I for example really like how the hibernate documentation is structure, i usually have to problem finding what i'm
Re: T5: What is NOT beautiful about Tapestry?
:43 AM To: Tapestry users users@tapestry.apache.org Subject: Re: T5: What is NOT beautiful about Tapestry? I totally agree with Hugo's ideia. The wiki sounds good and should be a easy to make documentation about common problems. 2009/4/30 Hugo Palma hugo.m.pa...@gmail.com I agree a book would be great, what happened to the tapestry5-book project http://code.google.com/p/tapestry5-book/ ? Still, i think a lot better could be done with the online documentation. I believe the structure of the online documentation should be very similar to a book, it should start with the basics and evolve to more hardcore stuff from there. Just the fact that the current documentation is structured with only one level of depth and the list of item is ordered alphabetically makes the task of finding some information much more difficult. I for example really like how the hibernate documentation is structure, i usually have to problem finding what i'm looking for there. So, maybe the wiki could be a starting place for the birth of a documentation with such a structure. On Thu, Apr 30, 2009 at 10:06 AM, Blower, Andy andy.blo...@proquest.co.uk wrote: I think you hit the nail on the head Carl. The documentation is okay generally (some bits poor, some very good) but there is not enough to tie it all together and guide new developers so they know what they can do with T5. I'm not convinced that the main documentation should attempt this on its own, or whether it should strive to be a great reference with some more higher level introductory/discovery bits along with a good published book to handle introducing everything and tying it together. Having the only published book for T5 being so out of date is a huge problem for the framework in my opinion. I don't think a wiki is the answer to this, I really like knowing that the documentation that I'm looking at is for a specific version of Tapestry and is updated when the code is - I would not want to lose that. Andy. -Original Message- From: Carl Crowder [mailto:carl.crow...@taptu.com] Sent: 29 April 2009 22:04 To: Tapestry users Subject: Re: T5: What is NOT beautiful about Tapestry? Discovery of it's parts. Franky the documentation is lacking and even with reading the mailing list, reading the howtos wiki, buying the Tapestry 5 book and working with it for over a year I still come across things I never knew existed that would have solved a problem I've had. I often spend ages writing something myself after searching for a solution. What's beautiful about Tapestry? That almost every problem has a simple solution built in. What's not beautiful about Tapestry? That I generally find these solutions by accident, and way after I've written my own! Lots of things are obvious and easy to understand once you know what they are but it's learning what they are that is the problem. I've been waxing lyrical about Tapestry where I work and while the developers who tried it love it, their main gripe is always that it's difficult to understand what it can do. The cookbook is the right idea but it's only got 5 entries right now. It needs to be way more comprehensive Inge Solvoll wrote: Hi! I have been reading the beautiful thread and added my opinion about what's great about Tapestry. It's nice to sum up why we all are so excited about this, it obviously makes both us and the creator(s) feel good about ourselves. But for a little while, I challenge us all to stop tapping each others' backs and go into depth about what's not to like about our beloved framework. The most obvious questions that could be asked probably have some very obvious answers. But T5, as I see it, is all about addressing stuff that other frameworks have given up on and create excellent implementations rather than just looking the other way. Difficult and uncomfortable questions should be addressed the same way. So: What are the main reasons that T5 isn't one of the big ones, when we all seem to agree that it is so much better than most other frameworks out there? Why is T5 NOT beautiful? Hope I'm not insulting anyone, I'm a big fan too, I just think this actually could lead to significant insight :) Regards Inge - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: What is NOT beautiful about Tapestry?
For Tap 3, we had a very elaborate form with loop implementation and we added Ajax-validation such that you only write validation code once in Java and for javascript validation, an ajax call is made to run the same validation code and bring back the results. The error handling could correctly handle n-input fields in a form all generated via a loop. Needless to say the code was quite complex and horrendously convoluted and now is outdated :( haha -- From: Inge Solvoll inge.tapes...@gmail.com Sent: Thursday, April 30, 2009 6:09 PM To: Tapestry users users@tapestry.apache.org Subject: Re: T5: What is NOT beautiful about Tapestry? Agree with Alex on the last comment about proving that issues don't exist! I have one example of a trivial thing that I have found difficult to implement in all Tapestry versions I have used(3, 4, 5): - A form with a loop in it. This is extremely common in the pages I make, and my mind always struggles when trying to find how this is done in the new Tapestry version. I never figured out a way to do it in 3 and 4 that made sense to me and looked correct. It also happened in T5. Maybe I'm stupid, but I really had to struggle hard to track down the details needed to implement this correctly, using encoders, initializing my form objects in the correct method in the correct way, and so on. I didn't find an example in the docs showing me the best practice for this (for me) very trivial and very common pattern. On Thu, Apr 30, 2009 at 11:17 PM, Alex Kotchnev akoch...@gmail.com wrote: I will echo Kranga's #1 and #2 and add a couple. I'm all for convention over configuration, but when you have to dig out the convention out of source code, mailing list, or somewhere else, I'd wish I had a well defined interface that I could just implement. The not-so-pojo aspect becomes too apparent when you have to write some test cases against the said components and you start scratching you head about now, how do I make all of those magical annotations work if I don't do the whole IoC bit where it will inject everything. One additional difficulty is that T5's model is so different in respect to AJAX that it takes a while to wrap (or warp) your head around what you need to do in order to do something seemingly simple w/ a known Javascript framework (e.g. think Dojo, Prototype, jQuery). There are a plethora of people out there that know how to make up a snazzy ajaxy interface; however, when it comes down to T5 you have to jump through a couple of hoops just to get the URL to which the Ajax code will hook into (e.g. the componentResources.createPageLink , createEventLink, etc). Componetization support and all within T5 is nice, but when you have to climb a big hill of learning a lot of T5 before you can do a silly autocompletion example for Dojo or jQuery, it just makes it harder than necessary. Certainly not a boon. Finally, it's great that T5 is so well decomposed into small interfaces , so that you can override anything you want. However, too many small classes/interfaces + a bunch of dependencies on each other (which are really easy to do when IoC can magically inject dependencies for you) starts being a drag when you want to implement/override one, and then you realize that in order to do one, you need to figure out a bunch more things that need to be injected (or something like that). It's really easy to get into a rabbit hole of oh, I wanted to implement this one thing, now I have to understand these other three before I can implement the first one Otho, I don't think the point of this thread is for us to prove that the issues that are brought up are not actually issues. The fact that people bring them up, means that those issues still exist. I doubt that someone will go through the trouble of typing up a big email regarding his troubles w/ T5 if these were not issues that he/she has dealt with. Cheers, Alex K On Thu, Apr 30, 2009 at 9:28 AM, kranga kra...@k2d2.org wrote: 1) Documentation: It is one thing to remove dependencies on framework interfaces but quite another to leave the developer hanging with no documentation. Programming by convention is programming in the dark if the convention is not known. 2) Although Tapestry claims to be POJO, you still have to have a contract (whether it is methods by convention or annotated methods). In the long run whether this is really better than interface implementation is not fully proven (much like the current debate of whether dynamically typed languages will prove more difficult to maintain in the long run). 3) Lack of a component marketplace: Wow, 4 years on and this is still on my list. We wrote a gigantic application in Tapestry 3 which is still in production. But we've decided to write all new apps in JSF with the aim of quickly adopting 2.0 when the spec is released. The main reason - a plethora of components to choose from. 4) Developer mindshare
Re: T5: What is NOT beautiful about Tapestry?
I agree, I think this will be a constructive thread. So things that are not beautiful yet are a lack of tooling, aside from the helpful Loom plugin. I only use eclipse here, so I'm not sure if there are plugins for other IDEs. Sometimes I wish there were more industry type examples out there, since I often find myself writing something that is overly verbose. I find myself looking at code on http://www.google.com/codesearch . Maybe a reproduction of the T4 Showcase app would make a good archetype. Maven usage used to be a problem for some, but I think most of us have gotten used to it or have worked around it. On Wed, Apr 29, 2009 at 4:19 PM, Inge Solvoll inge.tapes...@gmail.comwrote: Hi! I have been reading the beautiful thread and added my opinion about what's great about Tapestry. It's nice to sum up why we all are so excited about this, it obviously makes both us and the creator(s) feel good about ourselves. But for a little while, I challenge us all to stop tapping each others' backs and go into depth about what's not to like about our beloved framework. The most obvious questions that could be asked probably have some very obvious answers. But T5, as I see it, is all about addressing stuff that other frameworks have given up on and create excellent implementations rather than just looking the other way. Difficult and uncomfortable questions should be addressed the same way. So: What are the main reasons that T5 isn't one of the big ones, when we all seem to agree that it is so much better than most other frameworks out there? Why is T5 NOT beautiful? Hope I'm not insulting anyone, I'm a big fan too, I just think this actually could lead to significant insight :) Regards Inge
Re: T5: What is NOT beautiful about Tapestry?
Discovery of it's parts. Franky the documentation is lacking and even with reading the mailing list, reading the howtos wiki, buying the Tapestry 5 book and working with it for over a year I still come across things I never knew existed that would have solved a problem I've had. I often spend ages writing something myself after searching for a solution. What's beautiful about Tapestry? That almost every problem has a simple solution built in. What's not beautiful about Tapestry? That I generally find these solutions by accident, and way after I've written my own! Lots of things are obvious and easy to understand once you know what they are but it's learning what they are that is the problem. I've been waxing lyrical about Tapestry where I work and while the developers who tried it love it, their main gripe is always that it's difficult to understand what it can do. The cookbook is the right idea but it's only got 5 entries right now. It needs to be way more comprehensive Inge Solvoll wrote: Hi! I have been reading the beautiful thread and added my opinion about what's great about Tapestry. It's nice to sum up why we all are so excited about this, it obviously makes both us and the creator(s) feel good about ourselves. But for a little while, I challenge us all to stop tapping each others' backs and go into depth about what's not to like about our beloved framework. The most obvious questions that could be asked probably have some very obvious answers. But T5, as I see it, is all about addressing stuff that other frameworks have given up on and create excellent implementations rather than just looking the other way. Difficult and uncomfortable questions should be addressed the same way. So: What are the main reasons that T5 isn't one of the big ones, when we all seem to agree that it is so much better than most other frameworks out there? Why is T5 NOT beautiful? Hope I'm not insulting anyone, I'm a big fan too, I just think this actually could lead to significant insight :) Regards Inge - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: What is NOT beautiful about Tapestry?
The flexibility of T5, in that almost every task it performs is handled by a different service that can be overwritten has a downfall. It sometimes takes me a long time to figure out what service handles what task and how can it be overwritten (the under documentation argument obviously plays a role here). Some of the reflection can make debugging harder at times and annotations over POJO's takes some time to get used to (but maybe that is a java5+ wide argument). My 2 cents, Joost On Thu, Apr 30, 2009 at 8:19 AM, Inge Solvoll inge.tapes...@gmail.com wrote: Hi! I have been reading the beautiful thread and added my opinion about what's great about Tapestry. It's nice to sum up why we all are so excited about this, it obviously makes both us and the creator(s) feel good about ourselves. But for a little while, I challenge us all to stop tapping each others' backs and go into depth about what's not to like about our beloved framework. The most obvious questions that could be asked probably have some very obvious answers. But T5, as I see it, is all about addressing stuff that other frameworks have given up on and create excellent implementations rather than just looking the other way. Difficult and uncomfortable questions should be addressed the same way. So: What are the main reasons that T5 isn't one of the big ones, when we all seem to agree that it is so much better than most other frameworks out there? Why is T5 NOT beautiful? Hope I'm not insulting anyone, I'm a big fan too, I just think this actually could lead to significant insight :) Regards Inge - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: What is NOT beautiful about Tapestry?
The problem probably lies with the fact that many of us have learned T5 gradually while it was being developed and that is why most of the things seem easy and natural. It might not be so when you see the T5 for the first time. Don't get me wrong, I think everything is ok with the framework, but some more examples would certainly help. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: What is NOT beautiful about Tapestry?
So, we've clearly hit on documentation being an issue. ;) Two other things that I think are problematic for newcomers to tapestry: * static structure, dynamic behavior. I agree with HLS's choice on this, but it does create a barrier for a lot of people; the programming model in, eg, Wicket is just easier to wrap your head around: how do I dynamically get some different component on the page? Instantiate it Again, I'm not advocating changing static structure, dynamic behavior, but I wonder if there's a way that we can hurdle the barrier here... I have no ideas on this as yet. * Related to above, having pages that exist for no other reason than to be holders for components that will be dynamically injected seems a bit... ugly. Maybe we could have a dedicated dynamic component holder? At the very least, having a simple annotation such as: @DynamicComponentHolder on the page classes, and having tapestry recognize that the page isn't actually a page meant to be rendered directly, and take steps accordingly (shut down requests for those pages, etc.) might be nice. * Ajax. Zones rock, but otherwise, ajax in tapestry is still... lacking, IMHO. I think tapestry could go a /long/ way toward making things easier here. For instance, the form injector component: it's useful, but I find it painful to use, and, it's really only interesting if you're planning on dynamically adding additional form elements (or removing them). But things like dynamic updates of bits and pieces of forms are painful... tapestry really go out of its way to ensure that the same state available in rendering the request, or in a full post, is available during an ajax request (I'm thinking particularly of the fact that the Form isn't in the environment (unless you use form injector). Robert On Apr 29, 2009, at 4/294:04 PM , Pete Poulos wrote: I am currently learning tapestry and while I agree with the concept of Convention over Configuration, as newbie I would really like to see all of the conventions clearly documented in one location. As it is right now I feel that I have to hunt around for them and I am worried that there are conventions that I am not aware of. Also, the documentation seems to dive into the details fairly quickly. It would be nice to see a page which clearly defines the breadth/scope of Tapestry. What components/modules are there? What can they do? Where are they located? How can I learn more about them? I am impressed with what I have seen so far, but it has been hard to figure out how to start and to clearly answer the following question: What parts of Tapestry should I have under my belt before I can claim that I know Tapestry? Maybe some of these answers are there already and I have either overlooked them or been unable to find them. Pete - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: What is NOT beautiful about Tapestry?
Let's say that the don't get me wrong, I love Tapestry-part is implicit in all replies to this thread, so we're all covered :) Some more questions: 1. What, politically, made it hard to introduce T5 in your organisation? Who resisted, and why? 2. What, technically, made it hard to introduce/teach T5 among your programmer colleagues? (some already mentioned documentation) 3. Why is JSF more popular than Tapestry? Other than the obvious standard from Sun? Something about documentation again maybe? Ask the Spring guys about fighting against standards from Sun. They beat EJB... :) On Thu, Apr 30, 2009 at 12:08 AM, Robert Zeigler robe...@scazdl.org wrote: So, we've clearly hit on documentation being an issue. ;) Two other things that I think are problematic for newcomers to tapestry: * static structure, dynamic behavior. I agree with HLS's choice on this, but it does create a barrier for a lot of people; the programming model in, eg, Wicket is just easier to wrap your head around: how do I dynamically get some different component on the page? Instantiate it Again, I'm not advocating changing static structure, dynamic behavior, but I wonder if there's a way that we can hurdle the barrier here... I have no ideas on this as yet. * Related to above, having pages that exist for no other reason than to be holders for components that will be dynamically injected seems a bit... ugly. Maybe we could have a dedicated dynamic component holder? At the very least, having a simple annotation such as: @DynamicComponentHolder on the page classes, and having tapestry recognize that the page isn't actually a page meant to be rendered directly, and take steps accordingly (shut down requests for those pages, etc.) might be nice. * Ajax. Zones rock, but otherwise, ajax in tapestry is still... lacking, IMHO. I think tapestry could go a /long/ way toward making things easier here. For instance, the form injector component: it's useful, but I find it painful to use, and, it's really only interesting if you're planning on dynamically adding additional form elements (or removing them). But things like dynamic updates of bits and pieces of forms are painful... tapestry really go out of its way to ensure that the same state available in rendering the request, or in a full post, is available during an ajax request (I'm thinking particularly of the fact that the Form isn't in the environment (unless you use form injector). Robert On Apr 29, 2009, at 4/294:04 PM , Pete Poulos wrote: I am currently learning tapestry and while I agree with the concept of Convention over Configuration, as newbie I would really like to see all of the conventions clearly documented in one location. As it is right now I feel that I have to hunt around for them and I am worried that there are conventions that I am not aware of. Also, the documentation seems to dive into the details fairly quickly. It would be nice to see a page which clearly defines the breadth/scope of Tapestry. What components/modules are there? What can they do? Where are they located? How can I learn more about them? I am impressed with what I have seen so far, but it has been hard to figure out how to start and to clearly answer the following question: What parts of Tapestry should I have under my belt before I can claim that I know Tapestry? Maybe some of these answers are there already and I have either overlooked them or been unable to find them. Pete - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: What is NOT beautiful about Tapestry?
Inge Solvoll schrieb: 1. What, politically, made it hard to introduce T5 in your organisation? Who resisted, and why? I am sure there a two things which could help at promotion for convincing decision makers: Real big live sites running under tapestry and a good up to date book. 2. What, technically, made it hard to introduce/teach T5 among your programmer colleagues? (some already mentioned documentation) As bigger sites hardly start from scratch, I see the legacy reason as a big technical point. Usually big codebases rely on action/command focused frameworks (e.g. struts, spring mvc) and it is extremely hard to refactor them to page and component based ones. Also I see that frontend people are being used to work with JSP, freemarker etc. and are a bit hesitating to look at yet another templating technology. I really like tapestry concepts and helps a lot to think in different directions even if you don't use it in daily job. About tap-ioc I really like to java-code style injection and configuration instead for XML. - manuel aldana ald...@gmx.de software-engineering blog: http://www.aldana-online.de - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: What is NOT beautiful about Tapestry?
I'm working with tapestry for 6 months and my main problems were: - The lack of good documentation and common problems solutions documentation; - The static structure and dynamic behaviour need. Sometimes it's painfull when you need to have a reference for the component on the java code, when we want to have two exlusive blocks with the some field inside. 2009/4/29 manuel aldana ald...@gmx.de Inge Solvoll schrieb: 1. What, politically, made it hard to introduce T5 in your organisation? Who resisted, and why? I am sure there a two things which could help at promotion for convincing decision makers: Real big live sites running under tapestry and a good up to date book. 2. What, technically, made it hard to introduce/teach T5 among your programmer colleagues? (some already mentioned documentation) As bigger sites hardly start from scratch, I see the legacy reason as a big technical point. Usually big codebases rely on action/command focused frameworks (e.g. struts, spring mvc) and it is extremely hard to refactor them to page and component based ones. Also I see that frontend people are being used to work with JSP, freemarker etc. and are a bit hesitating to look at yet another templating technology. I really like tapestry concepts and helps a lot to think in different directions even if you don't use it in daily job. About tap-ioc I really like to java-code style injection and configuration instead for XML. - manuel aldana ald...@gmx.de software-engineering blog: http://www.aldana-online.de - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Cumprimentos... Pedro Januário
Re: T5: What is NOT beautiful about Tapestry?
I'm interested about this - can you elaborate what you mean by this? What about the structure is too static, and what dynamism are you looking for? Christian. On 29-Apr-09, at 19:16 , Pedro Januário wrote: - The static structure and dynamic behaviour need. Christian Edward Gruber e-mail: christianedwardgru...@gmail.com weblog: http://www.geekinasuit.com/ - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: What is NOT beautiful about Tapestry?
Ok, i will try to expose one of my issues. t:delegate t:to=activeMode/ t:block id=processFormFields_1 - Other fields select t:id=subject t:type=select t:model=prop:subjectModel t:value=prop:subject t:mixins=ck/OnEvent event=change onCompleteCallback=updateSubsubjects/ - Other fields /t:block t:block id=processFormFields_2 - Other fields select t:id=subject t:type=select t:model=prop:subjectModel t:value=prop:subject t:mixins=ck/OnEvent event=change onCompleteCallback=updateSubsubjects/ - Other fields /t:block The two blocks will never be displayed together, and i need the id of the component because i need to have component on the server side. I have solutionated my problem with a uggly solution. t:delegate t:to=activeMode/ t:block id=processFormFields_1 - Other fields t:delegate t:to=subjectBlock/ - Other fields /t:block t:block id=processFormFields_2 - Other fields t:delegate t:to=subjectBlock/ - Other fields /t:block t:block id=subjectBlock select t:id=subject t:type=select t:model=prop:subjectModel t:value=prop:subject t:mixins=ck/OnEvent event=change onCompleteCallback=updateSubsubjects/ /t:block This was one of the multiple times (and that i remember :D ) that i have faced this issue. I have worked with dynamic structure and liked that kind of behaviour but i know that dynamic structure my have some serious and dificult problems to solve. 2009/4/30 Christian Edward Gruber christianedwardgru...@gmail.com I'm interested about this - can you elaborate what you mean by this? What about the structure is too static, and what dynamism are you looking for? Christian. On 29-Apr-09, at 19:16 , Pedro Januário wrote: - The static structure and dynamic behaviour need. Christian Edward Gruber e-mail: christianedwardgru...@gmail.com weblog: http://www.geekinasuit.com/ - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Cumprimentos... Pedro Januário
