Tapestry 5, JPA and Hibernate

[Alessandro Bottoni]

Hi All,
I'm looking at the alternatives that are available for building the
persistence layer of a application in Tapestry 5 and I would be happy to
hear your opinion about a couple of topics:

1) I see that there is a support library for JPA and JPA2
(http://kenai.com/projects/tapestry-jpa) but the description page at
Kenai says that the project was started on september 2009 so I wonder:
Is this library already mature and usable, even for production?

2) Is it better to use JPA/JPA2 or Hibernate3 with Tapestry 5? Why?
(I would probably stick with Hibernate but I'm open to suggestions.)

3) In his Jumpstart's FAQ, Geoff Callender says:

"Why did the Data Access Object pattern ever exist? As I recall it had
two purposes: to abstract away the data sources, and to hide the
implementation of accessing the data. That is exactly what JPA (Java
Persistence Architecture, also known as EJB3 Persistence) does too. So I
argue that JPA has taken the place of the DAO and there's no need for us
to write our own. JumpStart uses JPA as its DAO."

(see: http://jumpstart.doublenegative.com.au/faq.html)

What do you think about this? Would you use the JPA entity also for
hosting some business logic? Would not this approach represent a net
lost of flexibilty (because of a lack of "loose coupling")?

4) Is there any good tutorial or any good working demo regarding the use
of Hibernate and/or Jpa with Tapestry5? At the moment I'm studying/using
the following tutorials and demos/apps.

a) HLS "quickstart" Maven archetype and "quickstart" tutorial at
http://tapestry.apache.org/ . (This does not cover any persistence topic
at all).
b) "Tapestry for non believers"
(http://www.infoq.com/articles/tapestry5-intro) (No persistence/ORM
covering)
c) AppFuse 2.1 (http://appfuse.org/display/APF/Home) (very good
"example" - covering persistence, security and a lot of other topics -
but also quite large and complex)
d) Tapestry Jumpstart (http://jumpstart.doublenegative.com.au/) (very
good but not covering Hibernate/JPA)

Is there anything else around worth mentioning?

TIA

[Thiago H. de Paula Figueiredo]

Em Mon, 14 Dec 2009 07:55:21 -0200, Alessandro Bottoni

Post by Alessandro Bottoni
Hi All,

Hi!

Post by Alessandro Bottoni
"Why did the Data Access Object pattern ever exist? As I recall it had
two purposes: to abstract away the data sources, and to hide the
implementation of accessing the data.

I agree!

Post by Alessandro Bottoni
That is exactly what JPA (Java
Persistence Architecture, also known as EJB3 Persistence) does too. So I
argue that JPA has taken the place of the DAO and there's no need for us
to write our own. JumpStart uses JPA as its DAO."

I disagree. If a DAO exists the abstract away the data source and the
*implementation of accessing the data*, JPA is one implementation,
Hibernate is another, purde JDBC is another, etc. What if you want to
change your persistence to Google's BigTable (low-level API) or HBase or
MongoDB or DB4O? You have to change business rule code (they use JPA
directly), and the DAO pattern was created exactly to avoid this kind of
sistuation.

Post by Alessandro Bottoni
What do you think about this? Would you use the JPA entity also for
hosting some business logic?

I put in an entity all the logic that can be implemented just by using its
fields values. Example: if I have an Order entity that has Items, the
getTotalValue() method is placed in Order. Anything else goes to the
business logic classes.

Post by Alessandro Bottoni
Would not this approach represent a net
lost of flexibilty (because of a lack of "loose coupling")?

IMHO, yes.

Post by Alessandro Bottoni
4) Is there any good tutorial or any good working demo regarding the use
of Hibernate and/or Jpa with Tapestry5? At the moment I'm studying/using
the following tutorials and demos/apps.

http://tapestry.apache.org/tapestry5.1/tapestry-hibernate/userguide.html
http://tapestry.apache.org/tapestry5.1/tapestry-hibernate-core/conf.html
--
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-***@tapestry.apache.org
For additional commands, e-mail: users-***@tapestry.apache.org

[Geoff Callender]

Post by Thiago H. de Paula Figueiredo

Post by Alessandro Bottoni
"Why did the Data Access Object pattern ever exist? As I recall it had
two purposes: to abstract away the data sources, and to hide the
implementation of accessing the data.

I agree!

Post by Alessandro Bottoni
That is exactly what JPA (Java
Persistence Architecture, also known as EJB3 Persistence) does too. So I
argue that JPA has taken the place of the DAO and there's no need for us
to write our own. JumpStart uses JPA as its DAO."

I disagree. If a DAO exists the abstract away the data source and the *implementation of accessing the data*, JPA is one implementation, Hibernate is another, purde JDBC is another, etc. What if you want to change your persistence to Google's BigTable (low-level API) or HBase or MongoDB or DB4O? You have to change business rule code (they use JPA directly), and the DAO pattern was created exactly to avoid this kind of sistuation.

You got me - JPA targets relational databases, so if you think that one day you might need to re-engineer your project to use a non-relational database then maybe it would be worth writing DAOs now as an extra layer of abstraction.

However, if you're happy to stick with relational, then JPA can be your DAO. You choose your relational persister at runtime, eg. Hibernate, TopLink, OpenJPA, etc.

Post by Thiago H. de Paula Figueiredo

Post by Alessandro Bottoni
What do you think about this? Would you use the JPA entity also for
hosting some business logic?

I put in an entity all the logic that can be implemented just by using its fields values. Example: if I have an Order entity that has Items, the getTotalValue() method is placed in Order. Anything else goes to the business logic classes.

I'm building a system right now with almost all business logic encapsulated in the entities. Most of the entity methods represent state changes (eg. toAccepted(..), toRejected(..), toBilling(..), toBilled(..)) and many of those methods either create related entities or call state change methods on related entities. This kind of encapsulation is exactly what OO was all about before EJB 1 and 2 came along and stuffed us back into a procedural world with an anaemic domain model ( http://martinfowler.com/bliki/AnemicDomainModel.html ). The total effect is like a myriad of state machines interacting with each other, just like the real world, and so far I'm really liking it.

Post by Thiago H. de Paula Figueiredo

Post by Alessandro Bottoni
Would not this approach represent a net
lost of flexibilty (because of a lack of "loose coupling")?

IMHO, yes.

If your entities represent the real world entities and the developer can clearly see they implement the same behaviours as the real world entities then it seems to me that it is the "right" coupling!

Post by Thiago H. de Paula Figueiredo

Post by Alessandro Bottoni
4) Is there any good tutorial or any good working demo regarding the use
of Hibernate and/or Jpa with Tapestry5? At the moment I'm studying/using
the following tutorials and demos/apps.

http://tapestry.apache.org/tapestry5.1/tapestry-hibernate/userguide.html
http://tapestry.apache.org/tapestry5.1/tapestry-hibernate-core/conf.html
--
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
---------------------------------------------------------------------

Cheers,

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

[Thiago H. de Paula Figueiredo]

Em Tue, 15 Dec 2009 00:34:25 -0200, Geoff Callender

Post by Geoff Callender
However, if you're happy to stick with relational, then JPA can be your
DAO. You choose your relational persister at runtime, eg. Hibernate,
TopLink, OpenJPA, etc.

You can be happy with relational persistence now, but maybe not tomorrow.
;)
Just to be very clear: when I say "JPA is not my DAO", I say "any class
outside my persistence layer doesn't use JPA directly". As long as you
define DAO interfaces that are technology-agnostic and your business rules
classes use them, I'm happy with any DAO implementation. :)

Post by Geoff Callender
I'm building a system right now with almost all business logic
encapsulated in the entities. Most of the entity methods represent state
changes (eg. toAccepted(..), toRejected(..), toBilling(..),
toBilled(..)) and many of those methods either create related entities
or call state change methods on related entities. This kind of
encapsulation is exactly what OO was all about before EJB 1 and 2 came
along and stuffed us back into a procedural world with an anaemic domain
model ( http://martinfowler.com/bliki/AnemicDomainModel.html ). The
total effect is like a myriad of state machines interacting with each
other, just like the real world, and so far I'm really liking it.

I don't like anemic models, but I don't like entity classes that talk to
DAOs or business rules classes, like the domain-driven model people love
to do. I never have an entity class with a save() or findById() method. I
like to think that an object must implement anything it can do inside its
data structure, but never access anything beyond it (data store, external
systems).

Post by Geoff Callender
If your entities represent the real world entities and the developer can
clearly see they implement the same behaviours as the real world
entities then it seems to me that it is the "right" coupling!

I think we agree, but we didn't realize it yet. :)
--
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-***@tapestry.apache.org
For additional commands, e-mail: users-***@tapestry.apache.org

[Kalle Korhonen]

On Mon, Dec 14, 2009 at 6:51 PM, Thiago H. de Paula Figueiredo

Post by Thiago H. de Paula Figueiredo
Em Tue, 15 Dec 2009 00:34:25 -0200, Geoff Callender

(Bravo Geoff!)

Post by Thiago H. de Paula Figueiredo
You can be happy with relational persistence now, but maybe not tomorrow. ;)
Just to be very clear: when I say "JPA is not my DAO", I say "any class
outside my persistence layer doesn't use JPA directly". As long as you
define DAO interfaces that are technology-agnostic and your business rules
classes use them, I'm happy with any DAO implementation. :)

That's just a typical overengineered design
(http://en.wikipedia.org/wiki/Overengineering). You've changed
languages and the hell has frozen many times over before you change
your persistence layer *if* you started with a relational database.

Post by Thiago H. de Paula Figueiredo
I don't like anemic models, but I don't like entity classes that talk to
DAOs or business rules classes, like the domain-driven model people love to
do. I never have an entity class with a save() or findById() method. I like
to think that an object must implement anything it can do inside its data
structure, but never access anything beyond it (data store, external
systems).

Surely transaction management is none of domain model's business, but
if you can represent a pure business rule in your domain model, why
not? You are not going to use that business logic anywhere else
anyway. Exactly how many layers of indirection do there need to be?
Most of the Java applications today are way over-engineered for their
purpose - while RoR and php folks are running circles around us.

Kalle

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

[Alessandro Bottoni]

Post by Kalle Korhonen
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

[Kalle Korhonen]

On Tue, Dec 15, 2009 at 1:40 AM, Alessandro Bottoni

Post by Alessandro Bottoni

Post by Kalle Korhonen
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.

Post by Alessandro Bottoni
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.

Post by Alessandro Bottoni
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-***@tapestry.apache.org
For additional commands, e-mail: users-***@tapestry.apache.org

[Thiago H. de Paula Figueiredo]

Em Tue, 15 Dec 2009 19:30:41 -0200, Kalle Korhonen

Post by Kalle Korhonen
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-***@tapestry.apache.org
For additional commands, e-mail: users-***@tapestry.apache.org

[Piero Sartini]

The only reason I still use it is the transaction management. Having time to
implement something similar in Tapestry-IoC is in my wishlist
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-***@tapestry.apache.org
For additional commands, e-mail: users-***@tapestry.apache.org

[Kalle Korhonen]

On Tue, Dec 15, 2009 at 1:30 PM, Kalle Korhonen

Post by Kalle Korhonen
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-***@tapestry.apache.org
For additional commands, e-mail: users-***@tapestry.apache.org

[Alessandro Bottoni]

Post by Kalle Korhonen
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 ;-)

Post by Kalle Korhonen
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).

Post by Kalle Korhonen
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.

Post by Kalle Korhonen
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.

Post by Kalle Korhonen
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).

Post by Kalle Korhonen
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.

Post by Kalle Korhonen
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.

Post by Kalle Korhonen
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.

Post by Kalle Korhonen
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 ;-)

Post by Kalle Korhonen
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.

[Thiago H. de Paula Figueiredo]

Em Tue, 15 Dec 2009 03:43:19 -0200, Kalle Korhonen

Post by Kalle Korhonen
That's just a typical overengineered design
(http://en.wikipedia.org/wiki/Overengineering).

What's overengineering for one can be fine for another and even
underengineering for a thir person. :)
My point is that different people have different ideas for what is the
right approach. Each one of them will have pros and cons. The best balance
is not something that has a single correct answer. That's why I named my
company Ars Machina (Latin for art of the machine): in software
development, there are always a number of different ways to do the same
thing and the art lies in the choices we make. ;)

Post by Kalle Korhonen
You've changed
languages and the hell has frozen many times over before you change
your persistence layer *if* you started with a relational database.

You're right, but having DAOs defined as interfaces surely help to write
unit tests. ;) Using Tapestry-IoC, it's easy to decorate or advise
services based in interfaces.

Post by Kalle Korhonen
Surely transaction management is none of domain model's business, but
if you can represent a pure business rule in your domain model, why
not?

I agree, as long as the object can do it just by looking at its fields and
fields's fields and so on. But that's just my personal choice, of course.

Post by Kalle Korhonen
You are not going to use that business logic anywhere else
anyway. Exactly how many layers of indirection do there need to be?

To me, 2 is adequate for the majority of applications (business rules and
persistence). :)

Post by Kalle Korhonen
Most of the Java applications today are way over-engineered for their
purpose - while RoR and php folks are running circles around us.

AFAIK, PHP development has a large tendency to write spaghetti code. The
RoR people seem to me to get a better balance, but the language is very
different (dynamic typed vs static typed), so I'm not comfortable to
compare it directly with Java.
--
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-***@tapestry.apache.org
For additional commands, e-mail: users-***@tapestry.apache.org

[Pierce T. Wetter III]

Post by Alessandro Bottoni
Hi All,
I'm looking at the alternatives that are available for building the
persistence layer of a application in Tapestry 5 and I would be happy to
1) I see that there is a support library for JPA and JPA2
(http://kenai.com/projects/tapestry-jpa) but the description page at
Is this library already mature and usable, even for production?

The project was started then, but piero had been using his library in production for while.

Neither tapestry-jpa or taptestry-hibernate are a lot of code. Tapestry-jpa comes in two flavors. All the work is being done on tapestry-jpa2, which is using the new stuff in JPA2 to make tapestry-jpa2 mostly feature complete with tapestry-hibernate in terms of having EntityValueEncoders and a GridDataSource.

So:

tapestry-jpa: Stable, not going to change, uses JPA 1.0

tapestry-jpa2: Slightly in flux. Has some new stuff which uses JPA 2.0, which is the only way to build some of the things that tapestry-hibernate provided. It wasn't working with EclipseLink a while back due to what looked liked a bug in EclipseLink-2.0-SNAPSHOT, but I haven't tried it recently. It's working ok for me using Hibernate-3.5.0-SNAPSHOT as my JPA persistence provider.

Post by Alessandro Bottoni
2) Is it better to use JPA/JPA2 or Hibernate3 with Tapestry 5? Why?
(I would probably stick with Hibernate but I'm open to suggestions.)

I'm kind of a noob, even though I'm one of the people working on tapestry-jpa.

Here's my opinion, which may be partially misinformed, hopefully people will correct me as necessary.

For both JPA/Hibernate, you have two ways to go:

1. Container-Managed EntityManagers and transactions.

By this I mean that you're using @PersistenceContext and such in your classes so that your web application container (i.e. GlassFish) manages the EntityManagers and the transactions. The Tapestry jumpstart uses this approach.

Advantages:
You can access more than one persistence unit.
Possibly the Container can do smart stuff like EntityManager pools?
Transaction stuff happens automatically and mysteriously for you.
Very much standardized.


Disadvantages:
No EntityValueEncoder that "remembers" entities in the session by just remembering their primary key. (Though you could make one easy enough I suspect).
No GridDataSource

2. Tapestry-Managed

2a. tapestry-hibernate
2b. tapestry-jpa

In this case, you're using @Inject to inject Sessions/EntityManagers as needed. You annotate methods with @CommitAfter when you want transactions committed.

Advantages:
Because you tell Tapestry up front about your single database connection, it can build EntityValueEncoder and GridDataSources that can pull in your objects as necessary.

Disadvantages:
You can only use one database connection.
You have to be more explicit about what does what in your application.
You'll have to do one thing for Tapestry, one thing for standalone code.

Summary:
You can just use the JPA annotations as is with Tapestry, and the container does the work.

If you want, you can use tapestry-jpa and tapestry-hibernate. They have a few more features you might find useful, but they lock you into one database connection. Then the Tapestry container is doing the work instead.


Pierce

The boundaries of my ignorance:

While I'm relatively new to Tapestry/JPA/Hibernate, I've been a WebObjects guy for 12+ years now. I'm just now moving into T/J/H because in my opinion, its just now that the existing tools have passed WebObjects which figured out most of these problems years ago. It's just that WO is getting stale, and the containers have gotten better such that its now really obvious that GlassFish/Tapestry/JPA is the best technology out there.

But its all relatively new to me. I started working on tapestry-jpa2 because it seemed to me that it was the best way to integrate JPA with Tapestry. Now I'm not so sure that cloning tapestry-hibernate was the right approach. Tapestry-hibernate is an IoC provider to build Hibernate sessions as needed, but the JPA guys already thought of this issue, so why not use the IoC stuff built into the container?

That is, I'm starting to think that the existing @PersistenceContext stuff is preferable to @Inject because its more flexible. So what makes more sense is to implement JPAGridDataSource as something that uses the JPA annotations instead, but to do that I have to understand the JPA/Container IOC vs. the Tapestry IOC a bit better, because one problem with @PersistenceContext is that it takes a static string for the name to inject. So JPAGridDataSource would have to be an abstract superclass and you would then have to build a concrete subclass for each persistence unit. Which would be trivial.

But that's not going to happen quickly, unless someone volunteers to mind meld with me over Skype. :-)






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

[Piero Sartini]

   1. Container-Managed EntityManagers and transactions.
EntityManagers and the transactions. The Tapestry jumpstart uses this approach.

It would be really great if this possibility would be available.
Unfortunately, @PersistenceContext does not work in Tapestry pages or
services. This whole JavaEE DI stuff is only available within servlets
or EJBs. That's why tapestry-jpa is neccessary.

Some time ago people said it is better to not depend on the servlet
api. They argumented it's bad if your controller classes need to
extend some base classes. Frameworks ignored the specification and now
they do not get all the great stuff for free that gets better and
better with each release of JavaEE.

Struts2, Wicket and many others do have the same problem. All of them
need to reinvent the wheel when it comes to persistence... tapestry
did the best job imho, but is not able to use JPA instead of the
hibernate APIs. That's where tapestry-jpa tries to help..


Piero

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

[Thiago H. de Paula Figueiredo]

Post by Piero Sartini
Struts2, Wicket and many others do have the same problem. All of them
need to reinvent the wheel when it comes to persistence... tapestry
did the best job imho, but is not able to use JPA instead of the
hibernate APIs.

I would say that Tapestry-IoC is not able to handle JPA fully
(@PersistenceContext) now, but someone can step up and implement this. :)
--
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-***@tapestry.apache.org
For additional commands, e-mail: users-***@tapestry.apache.org

[Piero Sartini]

Post by Thiago H. de Paula Figueiredo
I would say that Tapestry-IoC is not able to handle JPA fully

That's what I meant with re-inventing the wheel ;-)
One time we will have a working tapestry-jpa2 module. But then the
next step is to support more than one persistence context... and I
don't see we will catch up with the specification anytime soon.

There are already lots of working implementations of JavaEE
persistence.... but every single web framework needs to build one
implementation of its own, simulating the specification. Maybe I am
the only one, but I find this is lost developer power that should be
used to make the web parts of these frameworks better...

Piero

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

[Thiago H. de Paula Figueiredo]

Post by Piero Sartini
That's what I meant with re-inventing the wheel ;-)

You're right. :)

Post by Piero Sartini
There are already lots of working implementations of JavaEE
persistence.... but every single web framework needs to build one
implementation of its own, simulating the specification. Maybe I am
the only one, but I find this is lost developer power that should be
used to make the web parts of these frameworks better...

Maybe we could use some light EJB 3.x implementation integrated with
Tapestry-IoC (EJB-defined beans injectable as Tapestry-IoC services). This
is something that will be done eventually.
I've never used EJB, so I don't know what's the necessary effort to do
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-***@tapestry.apache.org
For additional commands, e-mail: users-***@tapestry.apache.org

[Dmitry Gusev]

Why don't just use spring to manage EntityManager and transactions?
This worked very well for me.

I've just published my "ping-service" project to github so that you can see
how JPA/Spring can be implemented in T5 app:

http://github.com/dmitrygusev/ping-service

I already mentioned this project here on mail list earlier and showed how
simple is this to inject EntityManager into my T5 services, just like this:

public class JobResultDAOImpl implements JobResultDAO {

@PersistenceContext
private EntityManager em;

@Override
public void persistResult(JobResult result) {
em.persist(result);
}

...


and you're done.



On Mon, Dec 14, 2009 at 22:21, Thiago H. de Paula Figueiredo <

Post by Piero Sartini
That's what I meant with re-inventing the wheel ;-)
You're right. :)
There are already lots of working implementations of JavaEE

Post by Piero Sartini
persistence.... but every single web framework needs to build one
implementation of its own, simulating the specification. Maybe I am
the only one, but I find this is lost developer power that should be
used to make the web parts of these frameworks better...

Maybe we could use some light EJB 3.x implementation integrated with
Tapestry-IoC (EJB-defined beans injectable as Tapestry-IoC services). This
is something that will be done eventually.
I've never used EJB, so I don't know what's the necessary effort to do
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
---------------------------------------------------------------------