>> I've also thought about this, and my only conclusion is that Tapestry is >> too difficult to master. Especially when it comes to tapestry-ioc and >> getting productive with it. > > What exactly is difficult to master? I think Tapestry-IoC is easier to learn > than Spring. > Maybe there's a sensation of Tapestry being hard to master because it's > built on IoC and has many hooks to do many things. Other frameworks has many > hooks, but less ways to customize them without changing the sources or doing > difficult configurations.
I never liked Spring because of its XML configuration. I like guice and tapestry-ioc better. What I meant is that it is hard to find your way around the IoC concepts neccessary to master tapestry.. I am learning something new every day, and do develop with tapestry 5 for about one year now. Some people say it is over engineered - I don't think so. But maybe its exposing too much of its excellence to the user, forcing us to be as excellent as the developers. Which brings me to another point: It is hard to contribute to tapestry, because you need a very high skillset to join the effort. It's _way_ easier to contribute to wicket or struts2. Result is, of course, that their codebase is not nearly as good as tapestry's. >> If I look at Wicket or other frameworks there are lots and lots of >> integration modules >> for just everything. Why is that? My answer is because it is way >> easier to write them. > > I guess is that because these frameworks are older and people had more time > to write these integration modules. Tapestry 5 is way younger, specially > when you think that the first stable version was released in December 18th, > 2009, one year and 5 days ago. Wicket 1.0 was released in June 2005, 4.5 > years ago. That's a 3.5 years head start. That may be one point. But our module landscape outside the core is really thin. And it is also hard to build some modules, because it would not be the tapestry way. Think about jQuery or other JS libraries (ExtJS, Dojo, etc) for example (IMHO the Prototype dependency frightened a lot of people). If you remember some weeks back, I was trying to integrate YAML (Yet another Multicolumn Layout: http://www.yaml.de) with tapestry... I gave up. Maybe because of lacking tapestry documentation.. but it is really not as easy as it should be! Tapestry claims to be flexible.. but adopting it to your needs is difficult (and not documented). > There isn't an integration with JFreeChart or JasperReports, for example, > maybe because it's so easy to write it (a page returning StreamResponse in > its onActivate() method). I agree :) >> But I would be perfectly fine trading the IoC container... > > The day you understand distributed configuration I guess you'll change your > mind. :) Guice does have all of this as well (and comes with warp-persist, offering JPA and db4o integrations - transactions as well). By the way, look out for google sitebricks... it reminds me a lot of tapestry. > I also use Spring, and I think Tapestry-IoC is bothe easier and more > powerful. See below, I don't even tried to use Spring.... starting with EJB3 there was no need to do so. > But what exactly do you find difficult in Tapestry-IoC? What could be > easier? What could be better documented? What have you tried to do with > T-IoC and failed? > Feedback is very important and we can use it to improve Tapestry and > Tapestry-IoC. ;) See above for two modules I tried to build with tapestry-ioc. My conclusion is that integrating third-party modules is too difficult. What I would love to be better documented is how to adopt the markup to your needs. Changing CSS is easy - but I did not find out how to change the markup yet. Piero --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
