Re: Christmas Wish List

[Alessandro Bottoni <al...@gmail.com>]

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