On Fri, 04 Mar 2011 06:11:59 -0300, Dany <du...@hotmail.com> wrote:
Hi,
Hi!
This works an data don´t blood in requester but at the you have to
controll in your code. We follow this pattern because our application is
complex and we have to make component, following 3 layers (with EJB
(business logic) + hibernate ) and not two like is orientated tapestry.
There's some misunderstanding here. Tapestry doesn't care at all about how
you architect your application. You could write an 1 or an 10 layers with
Tapestry as a front end.
In this structure at the end we have problems in the comunication between
components and Pages events + validations as well as data blood as we
disccuss in this thread.
Your code now avoids the data bleed.
I am not an expert in tapestry but I think that
data blood problems will have been controlled by the framework like it
was controlled in the version 5.01 or to clarify that the tapestry 5.2
has
changed become from a POJO to a tipically in a Servlet.
You could have what you call a data bleed in any Tapestry version if you
initialized a field in its declaration, unless the value is immutable.
A Tapestry class is a POJO, is *not* a servlet nor looks like one. What
Howard said is that 5.2 doesn't use a page pool anymore.
The Tapestry recommendation is that you initialize any fields needed in
render lifecycle events (@SetupRender, @BeginRender), the activate event
or even some component event (like the prepare event of Form).
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
