Sure, I will !
2014-09-18 14:21 GMT+02:00 Thiago H de Paula Figueiredo
:
> On Wed, 17 Sep 2014 20:40:28 -0300, Charlouze wrote:
>
> Hey again !
>>
>
> Hi!
>
> Sorry for bothering everyone but I just wanted to say that I think I
>> found my perfect solution. I was looking at
>> the EntityAppli
On Wed, 17 Sep 2014 20:40:28 -0300, Charlouze wrote:
Hey again !
Hi!
Sorry for bothering everyone but I just wanted to say that I think I
found my perfect solution. I was looking at
the EntityApplicationStatePersistenceStrategy class and it just gave me
my answer...
Maybe my new soluti
Hey again !
Sorry for bothering everyone but I just wanted to say that I think I found
my perfect solution. I was looking at
the EntityApplicationStatePersistenceStrategy class and it just gave me my
answer...
Maybe my new solution should replace the clumsy
EntityPersistentFieldStrategy of tapest
Hello everybody,
I'm really not sure about what I did and I really appreciate a feedback
from people who knows how persistent fields works.
If i'm not clear enough or anything about my issue, just let me know.
Cheers,
Charles.
2014-09-16 17:13 GMT+02:00 Charlouze :
> As for now, I solved my pr
As for now, I solved my problem using a new PersistentFieldStrategy and I
want your opinion about it:
public class MultiplePersistentFieldStrategy implements
PersistentFieldStrategy {
private final Logger logger;
private final List delegates;
public MultiplePersistentFieldStrategy(f
Hello Tapestry users & devs,
I have a component which does lots of ajax requests. Parameters setted at
the first render are not available upon ajax requests so I decided to
persist them in specific properties.
One of those parameter is a database entity (I use tapestry-jpa) so I
decided to use the
" email validation starts to work properly.
>> Looks
>> > like some magic :). However, I get sometimes user data lost. I can't
>> > reproduce this bug with 100% probability, but it occurs sometimes. I
>> tried
>> > also to change @Persist(PersistenceConstants.
bug with 100% probability, but it occurs sometimes. I
> tried
> > also to change @Persist(PersistenceConstants.FLASH) to default @Persist.
> > But
> > it gives me behavior I don't want - it renders user data even if I
> refresh
> > the pag
s bug with 100% probability, but it occurs sometimes. I tried
> also to change @Persist(PersistenceConstants.FLASH) to default @Persist.
> But
> it gives me behavior I don't want - it renders user data even if I refresh
> the page (I want to show blank form in that case). So FLASH persis
s. I tried
also to change @Persist(PersistenceConstants.FLASH) to default @Persist. But
it gives me behavior I don't want - it renders user data even if I refresh
the page (I want to show blank form in that case). So FLASH persistance is
what I want, but sometimes data are lost
o your current problem, but to
> tell
> > > > > Tapestry which constructor to use for the bean editor, you should
> > > > annotate
> > > > > the default (no args) constructor with @Inject - this will allow
> the
> > > BEF
> > >
hich constructor to use for the bean editor, you should
> > > annotate
> > > > the default (no args) constructor with @Inject - this will allow the
> > BEF
> > > to
> > > > create the relevant entity if none if present. Hope this helps.
>
ards,
> > > Jim.
> > >
> > > -Original Message-
> > > From: Anton Mezerny [mailto:anton.meze...@gmail.com]
> > > Sent: 23 October 2010 17:02
> > > To: Tapestry users
> > > Subject: Objects session persistance and validation
> > &
reate the relevant entity if none if present. Hope this helps.
> >
> > Regards,
> > Jim.
> >
> > -Original Message-
> > From: Anton Mezerny [mailto:anton.meze...@gmail.com]
> > Sent: 23 October 2010 17:02
> > To: Tapestry users
> > Subject: O
riginal Message-
> From: Anton Mezerny [mailto:anton.meze...@gmail.com]
> Sent: 23 October 2010 17:02
> To: Tapestry users
> Subject: Objects session persistance and validation
>
> Hi all,
> I'm trying to write simple registration form using beaneditor component.
> If I fullfill
gards,
Jim.
-Original Message-
From: Anton Mezerny [mailto:anton.meze...@gmail.com]
Sent: 23 October 2010 17:02
To: Tapestry users
Subject: Objects session persistance and validation
Hi all,
I'm trying to write simple registration form using beaneditor component.
If I fullfill all reqi
Hi all,
I'm trying to write simple registration form using beaneditor component.
If I fullfill all reqired fields in the form and submit it - everything
works fine, but if server validation occurs (for example passwords don't
match), then all data is lost and Registration page renders with validati
I think that can be done on a framework level with optional parameter
or annotation such as:
@Persist("lazy-thread-safe-session")
that locks in the beginning of the request and unlocks in the end.
However I don't think it's a priority feature.
As for me it's enough to just put reminder to "Pers
age -
> From: "Robert Zeigler"
> To: "Tapestry users"
> Sent: Tuesday, 14 July, 2009 17:03:22 GMT +02:00 Athens, Beirut, Bucharest,
> Istanbul
> Subject: Re: T5 Page field persistance and multithread problems
>
> Alfie, actually, many people have
Wizard SSOs are a typical example of the temporary state I mentioned. No one
else should be able to write to it and thus you don't need guards against
concurrent writes. Especially not, since you validate the business objects
before comitting them. But still it could be a neat idea in some
circumst
rut, Bucharest,
Istanbul
Subject: Re: T5 Page field persistance and multithread problems
2009/7/15
> Other than a flag that the framework will have to manage, I really don't
> see it being such a big deal... maybe I am naive and missing something, but
> do you think it is better for T
2009/7/15
> Other than a flag that the framework will have to manage, I really don't
> see it being such a big deal... maybe I am naive and missing something, but
> do you think it is better for Tapestry users to manage this? having Atomic
> references and Synchronized blocks all over our code, i
nd modules through a facade where all the transaction
handling,locking, ... is done.
g,
kris
p.stavrini...@albourne.com
15.07.2009 09:15
Bitte antworten an
"Tapestry users"
An
Tapestry users
Kopie
Thema
Re: T5 Page field persistance and multithread problems
> I suppose
:08:04 GMT +02:00 Athens, Beirut, Bucharest,
Istanbul
Subject: Re: T5 Page field persistance and multithread problems
On Tue, Jul 14, 2009 at 3:10 AM, kristjankelt wrote:
>
> Hi,
>
>
> Peter Stavrinides wrote:
>>
>> Kristjan, as Nille has explained to you that is simply not t
2009/7/14 Howard Lewis Ship
> I am loathe to have the framework manage this automatically because it
> causes its own problems.
>
> For example, it is reasonable to process multiple Ajax requests in
> parallel if they only read data.
Exactly. Concurrent write access to data should be handled wh
nce is set to Integer(1).
>
> Now this example involved only one variable and this was immutable (you can
> not change it's innerstate). Having multiple variables or immutable
> variables (like entity beans) will introduce more problems.
>
> Regards,
> Kristjan Kelt
> --
> V
many times you see
DIFFERENT.
Regards,
Kristjan Kelt
--
View this message in context:
http://www.nabble.com/T5-Page-field-persistance-and-multithread-problems-tp24468298p24485700.html
Sent from the Tapestry - User mailing list archive at Nabble.com
ss to the ServletContext.
Peter
- Original Message -
From: "Robert Zeigler"
To: "Tapestry users"
Sent: Tuesday, 14 July, 2009 17:03:22 GMT +02:00 Athens, Beirut, Bucharest,
Istanbul
Subject: Re: T5 Page field persistance and multithread problems
Alfie, actually, ma
tiple submits of a form? Although this would not affect your test
as
you have multiple browser windows.
Hope this makes sense,
Alfie.
-Original Message-
From: kristjankelt [mailto:kristjank...@hotmail.com]
Sent: 14 July 2009 11:11
To: users@tapestry.apache.org
Subject: Re: T5 Page
lt [mailto:kristjank...@hotmail.com]
Sent: 14 July 2009 11:11
To: users@tapestry.apache.org
Subject: Re: T5 Page field persistance and multithread problems
Hi,
Peter Stavrinides wrote:
>
> Kristjan, as Nille has explained to you that is simply not the case,
what
> is happening is multiple requests
> inherently
> stateless.
>
I think that my case is working because no care has been taken to make this
code thread safe.
Regards,
Kristjan Kelt
--
View this message in context:
http://www.nabble.com/T5-Page-field-persistance-and-multithread-problems-tp24468298p24478142.html
Sent fro
is reading from the session then it will still see
> the
> reference to Integer(1) and it's corrensponding page object private
> variable
> reference is set to Integer(1).
>
> Now this example involved only one variable and this was immutable (you can
> not change it&#
this was immutable (you can
not change it's innerstate). Having multiple variables or immutable
variables (like entity beans) will introduce more problems.
Regards,
Kristjan Kelt
--
View this message in context:
http://www.nabble.com/T5-Page-field-pe
uesday, 14 July, 2009 11:14:20 GMT +02:00 Athens, Beirut, Bucharest,
Istanbul
Subject: Re: Re: T5 Page field persistance and multithread problems
Hi,
I think that this is definitelly thread issue because data is shared between
multiple threads. Even when every page instance would have it'
>
> The only problem observed here is the double submit problem. That is not a
> bug of Tapestry but must be handled by every webapp no matter what
> framework. Ways to do this are unique ids for forms or a state field.
>
> Regards, nillehammer
> ==
> http://www.winfonet.eu
&
Ways
to do this are unique ids for forms or a state field.
Regards, nillehammer
==
http://www.winfonet.eu
- original Nachricht
Betreff: Re: T5 Page field persistance and multithread problems
Gesendet: Di, 14. Jul 2009
Von: Robert Zeigler
> Well, it /is/ the case that page fi
as about this problem then I'm more than
thankful to
hear about them.
Regards,
Kristjan Kelt
--
View this message in context:
http://www.nabble.com/T5-Page-field-persistance-and-multithread-problems-tp24468298p24468298.html
Sent from the Tapes
ge in context:
http://www.nabble.com/T5-Page-field-persistance-and-multithread-problems-tp24468298p24468298.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapest
ces and each page can overwrite the another. My searches didn't
>>>>
>>> come
>>>
>>>> up with a definitive answer although I did see that the question has
>>>> been
>>>> asked several times. Can anyone comment on this or provide a
ion has
> >> been
> >> > asked several times. Can anyone comment on this or provide a
> >> workaround?
> >> >
> >> >
> >> >
> >> > Peter Stavrinides wrote:
> >> > >
>
ugh
>>>>> information to
>>>>> run
>>>>> the report again. If the report page needed to be refreshed
>>>>> (such as
>>>>> sorting something on the page, non-async), the client side key
>>>>> would look
>
ational state covers some of this ground (the difference
being a
conversation is tied to not only the page, but the window so each
tab
is
treated as a new conversation)...
--
View this message in context:
http://www.nabble.com/Persistance-tp20732003p20743522.html
Sent from the Tapestry - U
gt;> up with a definitive answer although I did see that the question
>>>> has been
>>>> asked several times. Can anyone comment on this or provide a
>>>> workaround?
>>>>
>>>>
>>>>
>>>> Peter Stavrinides wrote:
&g
articularly the way pages are pooled, but since
conversational state covers some of this ground (the difference
being a
conversation is tied to not only the page, but the window so each
tab
is
treated as a new conversation)...
--
View this message in context:
http
user leaves the page.
>> In
>> > > truth someone posted such a solution which used a cookie, and it
>> seemed
>> > to
>> > > behave exactly as it should, nevertheless I am still against relying
>> on
>> a
>> > > cookie. I understand this
olution which used a cookie, and it seemed
> > to
> > > behave exactly as it should, nevertheless I am still against relying on
> a
> > > cookie. I understand this may be difficult to implement due to
> Tapestry's
> > > inner workings, particularly t
me of this ground (the difference being a
> > conversation is tied to not only the page, but the window so each tab is
> > treated as a new conversation)...
> >
>
> --
> View this message in context:
> http://www.nabble.com/Persistance-tp20732003p20743522.html
> Se
mber, 2008 12:52:37 PM GMT +02:00 Athens, Beirut,
Bucharest, Istanbul
Subject: Re: Persistance
I myself have found the need for such a persistence strategy.
I would suggest creating an issue for this so that people can vote and
follow it.
On Fri, Nov 28, 2008 at 10:23 AM, Peter Stavrinides
I myself have found the need for such a persistence strategy.
I would suggest creating an issue for this so that people can vote and
follow it.
On Fri, Nov 28, 2008 at 10:23 AM, Peter Stavrinides <
[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have been thinking about persistence lately... and after movi
Hi
Yeah in our T4 app we don't use @Persist at all and we really control the
session-size ... we have been setting up to open source this code that
handles the session issues.
I have been wanting to get the code in better shape before releasing back to
the community ... but it is good enough
I think this is very interesting too, and I have implemented something like
this in a menu component I've made, but the solution is specific to my case.
This persistence strategy would be a nice improvement, and would solve some
problems we had with the session size.
On Fri, Nov 28, 2008 at 7:23
tion)...
>
--
View this message in context:
http://www.nabble.com/Persistance-tp20732003p20743522.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi,
I have been thinking about persistence lately... and after moving all our apps
from Tapestry 4 to Tapestry 5 this past year, I have noticed distinct patterns
emerge in the way pages fit together and use persistence, and I have been
searching all the while for best practices... here are some
Yes, from what I understand persist is just to keep value between
request. so every-time you request the page the object is in this
case recreated.
If you want to keep this object across a session you need ASO (see T5
doc on persistence).
You can also (but will not be kept a session level
That is correct behavior, and if you update the property (not the set
stored in the property), then the Set will be stored into the session,
and restored on the next request.
On 4/8/07, Patrick Moore <[EMAIL PROTECTED]> wrote:
Hi there --
does anyone have some thoughts on why:
@Persist
Hi there --
does anyone have some thoughts on why:
@Persist
@InitialValue("new java.util.HashSet()")
public abstract Set getFollowUpMessages();
public abstract void setFollowUpMessages(Set set);
keeps on resetting the set to a new HashSet between http requests?
It looks like accord
Hi there --
does anyone have some thoughts on why:
@Persist
@InitialValue("new java.util.HashSet()")
public abstract Set getFollowUpMessages();
public abstract void setFollowUpMessages(Set set);
keeps on resetting the set to a new HashSet between http requests?
It looks like accord
57 matches
Mail list logo
