Il 15/12/2009 22:30, Kalle Korhonen ha scritto: > It's nice you mention Tynamo even though I've been rather careful > *not* to talk about it here yet before we have our house fully in > order.
Ooops! I apologize for having unveiled your secret ;-) > Tapestry is the enabling technology for both Tynamo and > AppFuse-T5, so I don't see these projects could easily be merged back > to T5. Well, no. I did not mean that. I just think we could coordinate Tapestry and its derived work, like Tynamo and AppFuse-T5 in order to have synchronized releases and coherent programming paradigms in all of them (see below for details). > Tapestry5 needs to keep going and improve the core without the > burden of extra dependencies. AppFuse in turn serves as a good > starter-app and showcase for a lot of different technologies not just > T5, Here we have an example of what we could do for improving the "developer's experience" about Tapestry 5. AppFuse is a wonderful and impressive piece of code and should continue to evolve on its own way. Despite this, I think that Tapestry 5 desperately needs a more sophisticated and complete Maven archetype, just like the one supplied by AppFuse. The AppFuse T5 archetype is very good but it is also very clear that from the AppFuse point of view Tapestry 5 is used almost just as a plug-in replacement for other, pre-existing presentation technologies, like Struts. Most of the overall architecture of AppFuse is completely Tapestry-indipendent and Tapestry-agnostic. While this is perfectly understandable (and engineeringly correct) from the point of view of AppFuse, it is not what we really need from the Tapestry point of view. We should have a AppFuse-like, "full-blown" archetype designed to use only Tapestry5 paradigms and to use them at their best. A showcase of Tapestry, not a showcase of AppFuse. Of course, it would be much easier to develop such a T5 showcase by coordinating the work with Matt Raible than reinventing AppFuse from scratch. > whereas the origins and focus of Tynamo is model-driven > development. Back when Trails was founded, it was primarily a > full-stack web application framework for model-driven development, but > the most requested feature was a more modularized approach since > people wanted to use bits and pieces of it without the full stack. Actually, my first bet was on Trails and I'm still studying and evaluating Tapestry5, AppFuse-T5 and Tynamo side-by-side. Tynamo could well be the Tapestry5 "full-blown" archetype and showcase I described earlier, even if its original goal was a completely different one. Actually, it is already evolving right in this way. The MDA approach is very interesting, as weel, and deserves all of our attention. Before taking into account Tapestry, I had a look at AndroMDA and at other MDA/MDD tools. I was really impressed with their approach (even if I have some doubt about their actual usability on the field). I do not see any reason why a full-stack, MDA/MDD tool should not use Tapestry5 as its own presentation layer and at its best, together with other required tools like Spring Security and Hibernate/Toplink/whatever. It is "just" a matter of modularization and you are already evolving Tynamo in this way. > also use only the parts you like from it. Luckily, the technology has > evolved. Without Maven, compiling these bits and pieces together so > you can have the best of both worlds was often just too difficult and I came from a Python (and sometime PHP) background. Even if most of usual tools used by Java developers are available, in a way or another, also in the Python world, the overall level of process "engineereability" of the Java world is much higher. Tools like Maven and Hudson are one of the reason we decided to switch to Java (together with ORMs like Hibernate, security libraries like Acegi and so on). > cumbersome even if it was technologically possible. Also with Trails, > the paradox was that even though it aimed at making building full web > applications easier, the underlying technologies were so complex that > you needed to know quite a bit about it to choose Trails in the first > place (as evident in the "Read me first" I wrote for Trails), which > also lead to only experienced people getting interested in it and > wanting to use only parts of it that suited them the best. This is the REAL problem with ALL Java-based frameworks. You just cannot use them before having studied in depth a lot of different technologies (Java itself, ORM libraries, Security libraries, IoC containers, servlet technology, etc.). This takes a lot of time and a huge amount of work. This is the REAL market opportunity for Tapestry5, as well. Should it succed in making more "accessible" the Java server-side world, it can make a epocal difference. It could well became for Java what RoR was for Ruby. > compared to RoR and some of the php frameworks, they have a pretty > good head start since they started years earlier than T5. For some on > the list, Tapestry5 is tried and true, but for most non-Java people > and corporates, Tapestry (5) is very much the bleeding edge that they > won't touch until it has gained significantly in popularity. Tapestry, Tynamo and AppFuse, like all other Java-based systems, are much more fit to large, complex projects developed by large and diverse teams. I do not think that the same people who uses RoR, Django or some RoR-like PHP framework would even take into account a Java framework like these. They just belong to different markets. Despite this, T5 and its derived works do are "bleeding edge" for us, who just have to develop a given system, in a given time and with a given amount of money. IMHO, the only way to transform them into "leading edge" system is to have full-blown, well-documented working showcases that can be used as starting points for real-world apps. > done that yet. On that note, I don't think multiple "derived systems" > will hinder the acceptance of T5 but help it. Marketing is a funny > thing - every now and then, and technological merits aside, a single > product or tool will manage become wildly popular, but most often than > not, it's difficult to clone the success of YouTube or RoR with one > new shiny thing. However, every new integration will help beating the > drum. I agree, absolutely. > EJB maybe, but I'm completely on a different track in regards to > Spring. Tapestry IoC is technologically far superior to Spring and at > the core of it, Spring is an IoC even if it offers mostly light > integrations to a plethora of other frameworks. At the same time, > Hibernate/EJB, Javamail etc. enabling technologies have become easier > to use and integrate on their so from my perspective, Spring is just > another layer of indirection that I'm campaigning to remove (and I say > that having used Spring extensively for years in multiple projects). Here I see that my limited knowledge of the English language brought me to say something completely opposite to what I meant. I completely agree with you about this topic. "Paying attention" to Spring was intended to mean "try to avoid it, if possible", like "pay attention to the cars" when crossing the road ;-) > Good luck with your Christmas wishes, hopefully I can contribute some > to your stocking! Many, many thanks for your attention and for your valuable time, Kalle. I just hope to go on fast and well in my study of these technology and to be able to contribute some code/docu in the future. I like this world and I would be happy to live into it. Merry Christmas and a happy new year. -- Alessandro Bottoni Website: http://www.alessandrobottoni.it/ Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law. — Douglas Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
