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 > >
