Il 23/12/2009 11:28, Piero Sartini ha scritto: >> I have an idea, may be a controversial one. I've seen much about Tapestry >> and think it's a nice Framework. But what I still don't understand is why >> it's not widely in use. It existed before Wicket but Wicket is far more >> popular. I don't think it's only because it's users are very vocal. There is >> also a saying that a good product sometimes sells itself. > > 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.
As a newbie, I have to say that learning Tapestry (5) is actually a little bit more complicated than what you could expect after having read the available "marketing" documentation. Maybe this (apparently steep) learning curve has kept the "masses" of developers/users away from Tapestry. Nevertheless, this apparent difficulty is in large part just a matter of documentation and/or examples. From this point of view, Wicket seems to be much more appetizing. Just have a look at these pages: http://wicketstuff.org/wicket13/ http://sourceforge.net/projects/wicket-stuff/files/ It is not surprising that many developers could prefer a framework that supply them with a lot of working, ready-to-use components and/or a lot of code examples. BEWARE: I'm not saying that Wicket /is/ better or more complete than Tapestry. I'm just saying that Wicket is /presented/ (or /offered/) to the public in a better way. I think that it is possible to fill this gap, for example using Tynamo and AppFuse as examples/codebases. At the end, it is just a matter of documentation and support. > I am not talking about building the frontend and components.. this is > easy and IMHO > the thing where tapestry really shines. I agree. Tapestry is much more elegant than many other frameworks from this point of view. This part of Tapestry should not be under discussion. I do not know if the IoC container is the real and sole source of the scarce appreciation of Tapestry (if even exists such a scarce appreciation) but... see below. > But there are way too less integrations - see my tapestry-jpa experiment for > an > example. It works, but it would need some love from some smarter people than > me > to get proper unit tests and some missing parts. > > 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'm afraid you are right: /this/ seems to be the main, real weak point of Tapestry. I do not know Tapestry well enough to have a solid opinion about this topic but it seems to me quite evident that writing an integration module is somehow (much?) more difficult than it should be. Unfortunately, this can be a heavy limit for Tapestry. A real webapp very often uses many external modules and the simple fact of not having a easy way to write and/or integrate them can be a good reason for abandoning this framework. I came from the Python world and, as you probably know, a large part of the success of Python is related to the easyness of integrating existing C and C++ library with the Python interpreter (using SIP or SWIG). It seems to me a lesson to learn. I wonder: is it possible to improve the existing integration mechanism of Tapestry (that is: the existing IoC container)? How? Or should we replace it with a different/new one? Which one? JM2C -- Alessandro Bottoni Website: http://www.alessandrobottoni.it/ Who wants to remember that escape-x-alt-control-left shift-b puts you into super-edit-debug-compile mode? -- (Discussion in comp.os.linux.misc on the intuitiveness of commands, especially Emacs.)
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
