Christmas Wish List (was: Tapestry 5, JPA and Hibernate)

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

Il 15/12/2009 06:43, Kalle Korhonen ha scritto:
> Most of the Java applications today are way over-engineered for their
> purpose - while RoR and php folks are running circles around us.

That's true. And that brings me to another, strictly related topic: the
learning curve of Tapestry 5.

On the Net there is a lot of very good documentation regarding Tapestry
and all of the technologies that it uses (Java, Hibernate, JPA,
Acegi/Spring Security, etc.). There are also a few very nice Open Source
applications that can be used as demos. Despite this wealth of learning
material, it can be still quite hard to find your way to develop a good
webapp with Tapestry 5, in particular if you come from a non-Java
background (like me).

IMHO this steep learning curve is due to two factors: the docu is still
lacking the type of organization/structure expected by the newbie and
the available demo apps are too much the expression of personal points
of view about the "right" way to develop a T5 app. I'm not going to
criticize the hard and excellent work done by other people in the last
few years so I will not examine these topics in further detail. Instead,
I will tell you what can be done to improve the existing situation,
IMVHO. Take this as my very personal Tapestry-related "wish list" for
Christmas.

1) Maven Archetypes
The existing "quickstart" is a very good starting point if you have to
develop a very particular system and, as a consequence, you have to
start from scratch, with the very least of burden of built-in features
to deal with.

Unfortunately, almost all of the projects that deserve the use of a
framework like Tapestry are not of this kind. Most likely, they will be
quite standard (and quite feature-rich) web app with a persistence
layer, a security subsystem (user-registration/access-control) and a few
other common features (captcha, full I18n support, etc.).

It would be fantastic to have /also/ a "not-so-quick start" Maven
archetype able to supply all, or near all, of the common features of a
standard webapp.

2) Derived systems
This brings me to AppFuse and Trails/Tynamo. These (and maybe other)
systems are actually much more than bare "derived systems". They serve
very well as learning tools (demo and working code examples) and as
really usable starting points for the development of real-world,
feature-rich apps.

Unfortunately, each and every of these derived systems are expression of
different approaches to the same problems and implements different
mechanisms to perform the same actions. Not all of the times the chosen
approach is the one that the developer would find most useful. This adds
complexity to an already complex world.

While I understand that T5, AppFuse and Tynamo cannot be easily merged
into a single project, I still think that the development process of
these projects could (and should) be somehow coordinated/synchronized.
The simple fact of having a community-agreed-upon, standardized,
"Tn-capable version" of Tynamo or AppFuse when version "n" of T appears
on the scene would save a lot of work and googling to the newbies like
me. This, in turn, would make Tapestry much more appreciated and diffused.

3) End-User Documentations
The sheer size of the existing (official and unofficial) documentation
of Tapestry, its basic technologies and its derived systems can be
intimidating for newbies. People coming from RoR or PHP are used to buy
a single 400 pages book, read it during the weekend and start developing
the next monday. Here you have to study (at least) Java (with
annotations, generics, collections, etc.), Hibernate/JPA, Acegi/Spring
Security, a few design patterns (IoC) and maybe a few other paradigms
(AOP with AspectJ, etc.).

Tapestry docu does not help from this point of view. Most of attention
is (understandably) devoted to experienced programmers and to (sometime
obscure) Tapestry internals. As a consequence, the newbie, like me, may
have to feeling to be observing a very complex and very fragile system.
This clashes with the image of a simple, robust system that the official
docu tries to diffuse.

What I personally would like most is a end-user documentation referring
to a working, feature-rich archetype (see above) and structured by
"macro" features/topics. Something like this:

a) Tapestry, the "not-so-basic" archetype, its setup and its use with
Eclipse (and/or Netbeans and/or IDEA, etc.)
b) Creating dynamic pages (.java, .tml, .properties) and
internationalize the whole systems
c) Creating and managing forms and persist their data into a DB using
Hibernate (or JPA).
d) Adding a access control system like Acegi
e) Adding a email address verification system by using a SMTP server
f) Creating custom components.
etc.

If you are wondering why the docu should explain how to reimplement and
use an already existing feature (like Acegi security, in this case),
think to how you normally study a framework. If you are used to examine
the existing code and play with it, you are just doing what this docu
would do. The difference is represented by the author that leads you in
the learning path.

I hope to see something like this into the ToC of the books that are
expected in the next months.

4) Dependencies
As Piero underlined in a previous message, many Java frameworks pay a
heavy tax for not using the available EJB3 services. Nevertheless, this
indipendency is a clear requirement for systems like Tapestry. Should I
have to study in depth and manage EJB or Spring for using Tapestry, most
likely I would just use EJB or Spring. It would just be simpler and
faster (even if not the right solution for the problem at hand).

For this reason, I think it should be paid some attention to use EJB,
Spring and other external services inside Tapestry derived systems (and
Tapestry standard, not-so-basic archetypes). While a few services, like
Acegi, can be integrated into Tapestry with little effort, others, like
the Spring IoC controller or some EJB service, can create the need to
study and dominate a completely different platform, driving the newbie
away form Tapestry.

As I told before, this is JM2C of contribution to the "marketing" of
Tapestry and its derived systems. I hope of not having stepped on
someone's else toe...

CU
-- 

Alessandro Bottoni
Website: http://www.alessandrobottoni.it/

It is not known with what weapon World War III will be fought,
but World War IV will be fought with sticks and stones.
     -- Albert Einstein

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

Re: Christmas Wish List (was: Tapestry 5, JPA and Hibernate)

[Kalle Korhonen <ka...@gmail.com>]

On Tue, Dec 15, 2009 at 1:30 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> 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. Tapestry is the enabling technology for both Tynamo and

Somebody already asked - the project site is at http://tynamo.org/ -
work in progress.

Kalle

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Christmas Wish List (was: Tapestry 5, JPA and Hibernate)

[Piero Sartini <li...@pierosartini.de>]

> The only reason I still use it is the transaction management. Having time to
> implement something similar in Tapestry-IoC is in my wishlist
> (tapestry-hibernate and @CommitAfter are not enough, as they're tied to
> Hibernate), but I don't know when Santa will give me that . . .

Yes.. transaction management is lacking. Also, while developed
tapestry-jpa I realized that it is not enough to clone
tapestry-hibernate. I am interested in alternative storage engines
(OODBMS like NeoDatis and db4o as well as distributed like HBase,
BigTable, MongoDB and others).

Especially for webapps, these alternative storage engines are very
attractive (and needed in large scale deployments) and I think we will
see them used more frequently.

What I would love to see is a more generic persistence module that
provides infrastructure to be implemented by modules. JPA would be
one, but it should be possible to integrate other strategies as well.
Maybe looking at NeoDatis could help.. in v2 they provide a storage
abstraction layer including transactions.

So my wishlist consists of 2 modules:
- for bleeding edge, innovative apps a tapestry-persistence module
including transaction support.
- for apps that need to integrate into existing java landscape, a
tapestry-ejb3 module.

Lots of work...

           Piero

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Christmas Wish List (was: Tapestry 5, JPA and Hibernate)

["Thiago H. de Paula Figueiredo" <th...@gmail.com>]

Em Tue, 15 Dec 2009 19:30:41 -0200, Kalle Korhonen  
<ka...@gmail.com> escreveu:

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

I agree completely. Tapestry-IoC's distributed configuration, for me, is  
valuable and powerful enough to try to get rid of Spring, and I didn't  
even talk about how Tapestry-IoC's configuration sintax is nicer than  
Spring's. The only reason I still use it is the transaction management.  
Having time to implement something similar in Tapestry-IoC is in my  
wishlist (tapestry-hibernate and @CommitAfter are not enough, as they're  
tied to Hibernate), but I don't know when Santa will give me that . . .

-- 
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da  
Informação Ltda.
http://www.arsmachina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Christmas Wish List (was: Tapestry 5, JPA and Hibernate)

[Kalle Korhonen <ka...@gmail.com>]

On Tue, Dec 15, 2009 at 1:40 AM, Alessandro Bottoni
<al...@gmail.com> wrote:
> Il 15/12/2009 06:43, Kalle Korhonen ha scritto:
>> Most of the Java applications today are way over-engineered for their
>> purpose - while RoR and php folks are running circles around us.
> That's true. And that brings me to another, strictly related topic: the
> learning curve of Tapestry 5.
> On the Net there is a lot of very good documentation regarding Tapestry
> and all of the technologies that it uses (Java, Hibernate, JPA,
> Acegi/Spring Security, etc.). There are also a few very nice Open Source
> applications that can be used as demos. Despite this wealth of learning
> material, it can be still quite hard to find your way to develop a good
> webapp with Tapestry 5, in particular if you come from a non-Java
> background (like me).

Java is somewhat of a victim of its own success. There's a wealth of
different libraries that often overlap in their intended use. People
have been building web applications for years, and every new, enabling
technology advancement has brought in a suite of new integration
libraries for making the same thing in a better way. And that's just
how it is, the new wheel *is* really needed: it's lighter, cheaper,
air-filled and more durable compared to the old wooden one. But I
agree with you and you are raising good points.

> 2) Derived systems
> While I understand that T5, AppFuse and Tynamo cannot be easily merged
> into a single project, I still think that the development process of
> these projects could (and should) be somehow coordinated/synchronized.
> The simple fact of having a community-agreed-upon, standardized,
> "Tn-capable version" of Tynamo or AppFuse when version "n" of T appears
> on the scene would save a lot of work and googling to the newbies like
> me. This, in turn, would make Tapestry much more appreciated and diffused.

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. 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. 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, 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. So,
current Tynamo development is a balancing act between the two: we want
provide a full-stack framework with loosely coupled modules so you can
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
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. Even though
you can see all the great ideas already in Tapestry4, Howard made
great strides at making them all much easier and more seamless to use
in Tapestry5. Consequently, Tynamo is and will be much easier to use
as well and I'm very happy to rephrase the warnings in "Read me first"
for Tynamo as well as writing a better, consumer/newbie-focused user
guide for Tynamo with proper links to excellent reference
documentation of Tapestry5. However, as things invariably are, this is
in-progress at the moment, but enough said about Tynamo. It would be
great of course if everything was released, clean and polished, but
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. I'm
fairly optimistic though and at times, even surprised it hasn't quite
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.

> For this reason, I think it should be paid some attention to use EJB,
> Spring and other external services inside Tapestry derived systems (and
> Tapestry standard, not-so-basic archetypes). While a few services, like
> Acegi, can be integrated into Tapestry with little effort, others, like
> the Spring IoC controller or some EJB service, can create the need to
> study and dominate a completely different platform, driving the newbie
> away form Tapestry.

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

Good luck with your Christmas wishes, hopefully I can contribute some
to your stocking!

Kalle

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org