On Fri, 04 Mar 2011 06:11:59 -0300, Dany 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) + hib
Hi,
Ok i provide you an example. Our objective is to build small component like
personal data, address etc... This small components are included in a Page.
Page will controller the validation for all components and general events.
For example:Page Tml
>
>
>
>
>
Page POJ
To reiterate: your code was broken in 5.1, just not as obviously as in 5.2.
On Wed, Mar 2, 2011 at 3:06 AM, Thiago H. de Paula Figueiredo
wrote:
> On Tue, 01 Mar 2011 23:30:42 -0300, Dany wrote:
>
>> Hi,
>
> Hi!
>
>> @Property
>> Private LoginVo loginVo;
>>
>> @Log
>>
On Tue, 01 Mar 2011 23:30:42 -0300, Dany wrote:
Hi,
Hi!
@Property
Private LoginVo loginVo;
@Log
@PageLoaded
void pageLoaded()
{
loginVo =new LoginVo();
}
@PageLoaded is triggered just once, when the page is instantia
Hi Howard,
Thanks for you soon reply. I have a doubt with repesct to you reply. If in
tapestry 5.2 it works with only one instance (like in a servlet) then it is
imposible to make the maching in a POJO/tml because this elements always is
going to be a mutable objects (in the same way that a servle
Yes, this is a subtle offshoot of the 5.2 changes. What you've done
is identify that single instance of LoginVO as the default value for
the loginVo field.
In 5.1, your bug was that different clients who accessed the same page
instance sequentially would see data bleed from one request to the
nex
Hi,
I am developing in tapestry 5.2. I have including pages and component but i
noticed one problem:
@Property
Private LoginVo loginVo;
@Log
@PageLoaded
void pageLoaded()
{
loginVo =new LoginVo();
}
if we include this v
