You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by "Norman W. Franke" <no...@myasd.com> on 2009/07/08 00:50:00 UTC
T5 Persistence Question
In the good old T4 days, I was able to persist form data between
submissions without using any session state since the values were
persisted in the fields themselves. This was very efficient,
particularly for very large forms (with several text areas containing
50K of data each.) As a further bonus, any properties marked as
"@Persist("client")" were stored in the form. This combined to make a
very memory-efficient application suitable for clustering.
Tapestry5 doesn't seem to allow this type of persistence, and clears
all properties when refreshing the page. (i.e. returning null from an
event handler.) This would seem to make T5 much, much less scalable
for applications with significant amounts of data entry since one
needs to persist the data in the session. A few 100K per session times
1000 or so sessions it a lot of RAM.
So, I saw that T5 has a @Persist("client") strategy, but it doesn't
appear to really be useful. It only stores the state in the URL. Is
there a way to store it in the form? Clearly, this will only work if
one has a form, but all my data entry forms will, obviously.
Is there a solution to this dilemma? Right now, T4 looks much more
efficient.
-Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5 Persistence Question
Posted by Jack Nuzbit <fn...@googlemail.com>.
I recently struggled with the same issue and in the end implemented a cookie
persist strategy similar to the one on the tapestry wiki. I've since
concluded that cookie persist strategies are far from ideal.
It would be great if tapestry could accommodate non-redirects on form errors
so persistent strategies could be avoided if reqiured.
Clustering sessions for scalable apps seems overkill if it's only needed for
form errors.
Jack
On Wed, Jul 8, 2009 at 8:04 PM, Norman Franke <no...@myasd.com> wrote:
> So let me be a little clearer:
>
> I don't want to run with SUPPRESS_REDIRECT_FROM_ACTION_REQUESTS = false,
> since that affects the entire application. There are definite benefits to
> the redirect model with bookmark-able URLs and proper operation of the
> browser's back button. However, it seems that having a way to disable this
> on validation errors (or other errors) from an action could be desired to
> enable better application scaling.
>
> In this case, keeping the URL the same would be fine. Bookmarking would
> bring them back to the default / blank state. It would have the problem with
> the back button having one's browser want to re-submit the data, but I don't
> really see that as a problem for error recovery. Sounds like a good tradeoff
> that developers may want to make rather than clutter up the session with
> 100s of K of data (huge forms) and preventing multiple instances of the same
> page from working independently in the same session.
>
> Either an annotation, setting a parameter on the response or even returning
> some special wrapper object (e.g. "return new DoNotRedirect(this)")?
>
> Norman Franke
> Answering Service for Directors, Inc.
> www.myasd.com
>
>
>
> On Jul 8, 2009, at 1:46 PM, Norman Franke wrote:
>
> That did fix it, and seems to imply that the client strategy is rather
>> useless in all but a very few cases. Is there some way to suppress redirect
>> for a specific action?
>>
>> Norman Franke
>> Answering Service for Directors, Inc.
>> www.myasd.com
>>
>>
>>
>> On Jul 8, 2009, at 1:30 PM, Robert Zeigler wrote:
>>
>> I think the previous reply to this post is correct: the form is correctly
>>> submitting w/ the various values stashed as hidden form fields. But on
>>> returning null from onSuccess, to re-render the current page, tapestry is
>>> sending a client redirect to the url for the page, and that url, of
>>> necessity, must include the client-persisted values within the URL.
>>> You could test this theory by suppressing client-side redirects, at least
>>> temporarily.
>>>
>>> From org.apache.tapestry5.SymbolConstants:
>>>
>>> /**
>>> * If set to true, then action requests will render a page markup response
>>> immediately, rather than sending a
>>> * redirect to render the response.
>>> */
>>> public static final String SUPPRESS_REDIRECT_FROM_ACTION_REQUESTS =
>>> "tapestry.suppress-redirect-from-action-requests";
>>>
>>>
>>> so contribute to application defaults and set
>>> SUPPRESS_REDIRECT_FROM_ACTION_REQUESTS to be false.
>>>
>>> That should at least help you figure out if it's the redirect that's
>>> pushing the values back into the url, as suspected.
>>>
>>> Robert
>>>
>>> On Jul 8, 2009, at 7/811:11 AM , Norman Franke wrote:
>>>
>>> How should the client strategy work? Am I misusing it from the onSuccess
>>>> callback?
>>>>
>>>> Norman Franke
>>>> Answering Service for Directors, Inc.
>>>> www.myasd.com
>>>>
>>>>
>>>>
>>>> On Jul 7, 2009, at 7:09 PM, Norman Franke wrote:
>>>>
>>>> On my page, it isn't happening. It gets stuck in the URL. My
>>>>> "onSuccess()" method does some further checking, and then returns. I get a
>>>>> huge URL. Does this not work from onSuccess?
>>>>>
>>>>> Norman Franke
>>>>> Answering Service for Directors, Inc.
>>>>> www.myasd.com
>>>>>
>>>>>
>>>>>
>>>>> On Jul 7, 2009, at 6:59 PM, Robert Zeigler wrote:
>>>>>
>>>>> I haven't looked closely, but my impression was that T5's
>>>>>> @Persist("client") will encode the values to form fields when there's a form
>>>>>> present. I'm pretty sure that's what's intended...
>>>>>>
>>>>>> Robert
>>>>>>
>>>>>> On Jul 7, 2009, at 7/75:50 PM , Norman W. Franke wrote:
>>>>>>
>>>>>> In the good old T4 days, I was able to persist form data between
>>>>>>> submissions without using any session state since the values were persisted
>>>>>>> in the fields themselves. This was very efficient, particularly for very
>>>>>>> large forms (with several text areas containing 50K of data each.) As a
>>>>>>> further bonus, any properties marked as "@Persist("client")" were stored in
>>>>>>> the form. This combined to make a very memory-efficient application suitable
>>>>>>> for clustering.
>>>>>>>
>>>>>>> Tapestry5 doesn't seem to allow this type of persistence, and clears
>>>>>>> all properties when refreshing the page. (i.e. returning null from an event
>>>>>>> handler.) This would seem to make T5 much, much less scalable for
>>>>>>> applications with significant amounts of data entry since one needs to
>>>>>>> persist the data in the session. A few 100K per session times 1000 or so
>>>>>>> sessions it a lot of RAM.
>>>>>>>
>>>>>>> So, I saw that T5 has a @Persist("client") strategy, but it doesn't
>>>>>>> appear to really be useful. It only stores the state in the URL. Is there a
>>>>>>> way to store it in the form? Clearly, this will only work if one has a form,
>>>>>>> but all my data entry forms will, obviously.
>>>>>>>
>>>>>>> Is there a solution to this dilemma? Right now, T4 looks much more
>>>>>>> efficient.
>>>>>>>
>>>>>>> -Norman
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>
Re: T5 Persistence Question
Posted by Norman Franke <no...@myasd.com>.
So let me be a little clearer:
I don't want to run with SUPPRESS_REDIRECT_FROM_ACTION_REQUESTS =
false, since that affects the entire application. There are definite
benefits to the redirect model with bookmark-able URLs and proper
operation of the browser's back button. However, it seems that having
a way to disable this on validation errors (or other errors) from an
action could be desired to enable better application scaling.
In this case, keeping the URL the same would be fine. Bookmarking
would bring them back to the default / blank state. It would have the
problem with the back button having one's browser want to re-submit
the data, but I don't really see that as a problem for error recovery.
Sounds like a good tradeoff that developers may want to make rather
than clutter up the session with 100s of K of data (huge forms) and
preventing multiple instances of the same page from working
independently in the same session.
Either an annotation, setting a parameter on the response or even
returning some special wrapper object (e.g. "return new
DoNotRedirect(this)")?
Norman Franke
Answering Service for Directors, Inc.
www.myasd.com
On Jul 8, 2009, at 1:46 PM, Norman Franke wrote:
> That did fix it, and seems to imply that the client strategy is
> rather useless in all but a very few cases. Is there some way to
> suppress redirect for a specific action?
>
> Norman Franke
> Answering Service for Directors, Inc.
> www.myasd.com
>
>
>
> On Jul 8, 2009, at 1:30 PM, Robert Zeigler wrote:
>
>> I think the previous reply to this post is correct: the form is
>> correctly submitting w/ the various values stashed as hidden form
>> fields. But on returning null from onSuccess, to re-render the
>> current page, tapestry is sending a client redirect to the url for
>> the page, and that url, of necessity, must include the client-
>> persisted values within the URL.
>> You could test this theory by suppressing client-side redirects, at
>> least temporarily.
>>
>> From org.apache.tapestry5.SymbolConstants:
>>
>> /**
>> * If set to true, then action requests will render a page markup
>> response immediately, rather than sending a
>> * redirect to render the response.
>> */
>> public static final String SUPPRESS_REDIRECT_FROM_ACTION_REQUESTS =
>> "tapestry.suppress-redirect-from-action-requests";
>>
>>
>> so contribute to application defaults and set
>> SUPPRESS_REDIRECT_FROM_ACTION_REQUESTS to be false.
>>
>> That should at least help you figure out if it's the redirect
>> that's pushing the values back into the url, as suspected.
>>
>> Robert
>>
>> On Jul 8, 2009, at 7/811:11 AM , Norman Franke wrote:
>>
>>> How should the client strategy work? Am I misusing it from the
>>> onSuccess callback?
>>>
>>> Norman Franke
>>> Answering Service for Directors, Inc.
>>> www.myasd.com
>>>
>>>
>>>
>>> On Jul 7, 2009, at 7:09 PM, Norman Franke wrote:
>>>
>>>> On my page, it isn't happening. It gets stuck in the URL. My
>>>> "onSuccess()" method does some further checking, and then
>>>> returns. I get a huge URL. Does this not work from onSuccess?
>>>>
>>>> Norman Franke
>>>> Answering Service for Directors, Inc.
>>>> www.myasd.com
>>>>
>>>>
>>>>
>>>> On Jul 7, 2009, at 6:59 PM, Robert Zeigler wrote:
>>>>
>>>>> I haven't looked closely, but my impression was that T5's
>>>>> @Persist("client") will encode the values to form fields when
>>>>> there's a form present. I'm pretty sure that's what's intended...
>>>>>
>>>>> Robert
>>>>>
>>>>> On Jul 7, 2009, at 7/75:50 PM , Norman W. Franke wrote:
>>>>>
>>>>>> In the good old T4 days, I was able to persist form data
>>>>>> between submissions without using any session state since the
>>>>>> values were persisted in the fields themselves. This was very
>>>>>> efficient, particularly for very large forms (with several text
>>>>>> areas containing 50K of data each.) As a further bonus, any
>>>>>> properties marked as "@Persist("client")" were stored in the
>>>>>> form. This combined to make a very memory-efficient application
>>>>>> suitable for clustering.
>>>>>>
>>>>>> Tapestry5 doesn't seem to allow this type of persistence, and
>>>>>> clears all properties when refreshing the page. (i.e. returning
>>>>>> null from an event handler.) This would seem to make T5 much,
>>>>>> much less scalable for applications with significant amounts of
>>>>>> data entry since one needs to persist the data in the session.
>>>>>> A few 100K per session times 1000 or so sessions it a lot of RAM.
>>>>>>
>>>>>> So, I saw that T5 has a @Persist("client") strategy, but it
>>>>>> doesn't appear to really be useful. It only stores the state in
>>>>>> the URL. Is there a way to store it in the form? Clearly, this
>>>>>> will only work if one has a form, but all my data entry forms
>>>>>> will, obviously.
>>>>>>
>>>>>> Is there a solution to this dilemma? Right now, T4 looks much
>>>>>> more efficient.
>>>>>>
>>>>>> -Norman
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
Re: T5 Persistence Question
Posted by Norman Franke <no...@myasd.com>.
That did fix it, and seems to imply that the client strategy is rather
useless in all but a very few cases. Is there some way to suppress
redirect for a specific action?
Norman Franke
Answering Service for Directors, Inc.
www.myasd.com
On Jul 8, 2009, at 1:30 PM, Robert Zeigler wrote:
> I think the previous reply to this post is correct: the form is
> correctly submitting w/ the various values stashed as hidden form
> fields. But on returning null from onSuccess, to re-render the
> current page, tapestry is sending a client redirect to the url for
> the page, and that url, of necessity, must include the client-
> persisted values within the URL.
> You could test this theory by suppressing client-side redirects, at
> least temporarily.
>
> From org.apache.tapestry5.SymbolConstants:
>
> /**
> * If set to true, then action requests will render a page markup
> response immediately, rather than sending a
> * redirect to render the response.
> */
> public static final String SUPPRESS_REDIRECT_FROM_ACTION_REQUESTS =
> "tapestry.suppress-redirect-from-action-requests";
>
>
> so contribute to application defaults and set
> SUPPRESS_REDIRECT_FROM_ACTION_REQUESTS to be false.
>
> That should at least help you figure out if it's the redirect that's
> pushing the values back into the url, as suspected.
>
> Robert
>
> On Jul 8, 2009, at 7/811:11 AM , Norman Franke wrote:
>
>> How should the client strategy work? Am I misusing it from the
>> onSuccess callback?
>>
>> Norman Franke
>> Answering Service for Directors, Inc.
>> www.myasd.com
>>
>>
>>
>> On Jul 7, 2009, at 7:09 PM, Norman Franke wrote:
>>
>>> On my page, it isn't happening. It gets stuck in the URL. My
>>> "onSuccess()" method does some further checking, and then returns.
>>> I get a huge URL. Does this not work from onSuccess?
>>>
>>> Norman Franke
>>> Answering Service for Directors, Inc.
>>> www.myasd.com
>>>
>>>
>>>
>>> On Jul 7, 2009, at 6:59 PM, Robert Zeigler wrote:
>>>
>>>> I haven't looked closely, but my impression was that T5's
>>>> @Persist("client") will encode the values to form fields when
>>>> there's a form present. I'm pretty sure that's what's intended...
>>>>
>>>> Robert
>>>>
>>>> On Jul 7, 2009, at 7/75:50 PM , Norman W. Franke wrote:
>>>>
>>>>> In the good old T4 days, I was able to persist form data between
>>>>> submissions without using any session state since the values
>>>>> were persisted in the fields themselves. This was very
>>>>> efficient, particularly for very large forms (with several text
>>>>> areas containing 50K of data each.) As a further bonus, any
>>>>> properties marked as "@Persist("client")" were stored in the
>>>>> form. This combined to make a very memory-efficient application
>>>>> suitable for clustering.
>>>>>
>>>>> Tapestry5 doesn't seem to allow this type of persistence, and
>>>>> clears all properties when refreshing the page. (i.e. returning
>>>>> null from an event handler.) This would seem to make T5 much,
>>>>> much less scalable for applications with significant amounts of
>>>>> data entry since one needs to persist the data in the session. A
>>>>> few 100K per session times 1000 or so sessions it a lot of RAM.
>>>>>
>>>>> So, I saw that T5 has a @Persist("client") strategy, but it
>>>>> doesn't appear to really be useful. It only stores the state in
>>>>> the URL. Is there a way to store it in the form? Clearly, this
>>>>> will only work if one has a form, but all my data entry forms
>>>>> will, obviously.
>>>>>
>>>>> Is there a solution to this dilemma? Right now, T4 looks much
>>>>> more efficient.
>>>>>
>>>>> -Norman
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
Re: T5 Persistence Question
Posted by Robert Zeigler <ro...@scazdl.org>.
I think the previous reply to this post is correct: the form is
correctly submitting w/ the various values stashed as hidden form
fields. But on returning null from onSuccess, to re-render the
current page, tapestry is sending a client redirect to the url for the
page, and that url, of necessity, must include the client-persisted
values within the URL.
You could test this theory by suppressing client-side redirects, at
least temporarily.
From org.apache.tapestry5.SymbolConstants:
/**
* If set to true, then action requests will render a page markup
response immediately, rather than sending a
* redirect to render the response.
*/
public static final String SUPPRESS_REDIRECT_FROM_ACTION_REQUESTS =
"tapestry.suppress-redirect-from-action-requests";
so contribute to application defaults and set
SUPPRESS_REDIRECT_FROM_ACTION_REQUESTS to be false.
That should at least help you figure out if it's the redirect that's
pushing the values back into the url, as suspected.
Robert
On Jul 8, 2009, at 7/811:11 AM , Norman Franke wrote:
> How should the client strategy work? Am I misusing it from the
> onSuccess callback?
>
> Norman Franke
> Answering Service for Directors, Inc.
> www.myasd.com
>
>
>
> On Jul 7, 2009, at 7:09 PM, Norman Franke wrote:
>
>> On my page, it isn't happening. It gets stuck in the URL. My
>> "onSuccess()" method does some further checking, and then returns.
>> I get a huge URL. Does this not work from onSuccess?
>>
>> Norman Franke
>> Answering Service for Directors, Inc.
>> www.myasd.com
>>
>>
>>
>> On Jul 7, 2009, at 6:59 PM, Robert Zeigler wrote:
>>
>>> I haven't looked closely, but my impression was that T5's
>>> @Persist("client") will encode the values to form fields when
>>> there's a form present. I'm pretty sure that's what's intended...
>>>
>>> Robert
>>>
>>> On Jul 7, 2009, at 7/75:50 PM , Norman W. Franke wrote:
>>>
>>>> In the good old T4 days, I was able to persist form data between
>>>> submissions without using any session state since the values were
>>>> persisted in the fields themselves. This was very efficient,
>>>> particularly for very large forms (with several text areas
>>>> containing 50K of data each.) As a further bonus, any properties
>>>> marked as "@Persist("client")" were stored in the form. This
>>>> combined to make a very memory-efficient application suitable for
>>>> clustering.
>>>>
>>>> Tapestry5 doesn't seem to allow this type of persistence, and
>>>> clears all properties when refreshing the page. (i.e. returning
>>>> null from an event handler.) This would seem to make T5 much,
>>>> much less scalable for applications with significant amounts of
>>>> data entry since one needs to persist the data in the session. A
>>>> few 100K per session times 1000 or so sessions it a lot of RAM.
>>>>
>>>> So, I saw that T5 has a @Persist("client") strategy, but it
>>>> doesn't appear to really be useful. It only stores the state in
>>>> the URL. Is there a way to store it in the form? Clearly, this
>>>> will only work if one has a form, but all my data entry forms
>>>> will, obviously.
>>>>
>>>> Is there a solution to this dilemma? Right now, T4 looks much
>>>> more efficient.
>>>>
>>>> -Norman
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5 Persistence Question
Posted by Norman Franke <no...@myasd.com>.
How should the client strategy work? Am I misusing it from the
onSuccess callback?
Norman Franke
Answering Service for Directors, Inc.
www.myasd.com
On Jul 7, 2009, at 7:09 PM, Norman Franke wrote:
> On my page, it isn't happening. It gets stuck in the URL. My
> "onSuccess()" method does some further checking, and then returns. I
> get a huge URL. Does this not work from onSuccess?
>
> Norman Franke
> Answering Service for Directors, Inc.
> www.myasd.com
>
>
>
> On Jul 7, 2009, at 6:59 PM, Robert Zeigler wrote:
>
>> I haven't looked closely, but my impression was that T5's
>> @Persist("client") will encode the values to form fields when
>> there's a form present. I'm pretty sure that's what's intended...
>>
>> Robert
>>
>> On Jul 7, 2009, at 7/75:50 PM , Norman W. Franke wrote:
>>
>>> In the good old T4 days, I was able to persist form data between
>>> submissions without using any session state since the values were
>>> persisted in the fields themselves. This was very efficient,
>>> particularly for very large forms (with several text areas
>>> containing 50K of data each.) As a further bonus, any properties
>>> marked as "@Persist("client")" were stored in the form. This
>>> combined to make a very memory-efficient application suitable for
>>> clustering.
>>>
>>> Tapestry5 doesn't seem to allow this type of persistence, and
>>> clears all properties when refreshing the page. (i.e. returning
>>> null from an event handler.) This would seem to make T5 much, much
>>> less scalable for applications with significant amounts of data
>>> entry since one needs to persist the data in the session. A few
>>> 100K per session times 1000 or so sessions it a lot of RAM.
>>>
>>> So, I saw that T5 has a @Persist("client") strategy, but it
>>> doesn't appear to really be useful. It only stores the state in
>>> the URL. Is there a way to store it in the form? Clearly, this
>>> will only work if one has a form, but all my data entry forms
>>> will, obviously.
>>>
>>> Is there a solution to this dilemma? Right now, T4 looks much more
>>> efficient.
>>>
>>> -Norman
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
Re: T5 Persistence Question
Posted by Martin Strand <do...@gmail.com>.
Perhaps the form submission leads to an url without parameters: /yourpage.form.action
but then results in a redirect to /yourpage?t:state=... where the state is visible?
In T4, if you returned null from a listener it would render the current page.
T5 redirects back to the current page before the render happens.
On Wed, 08 Jul 2009 01:09:36 +0200, Norman Franke <no...@myasd.com> wrote:
> On my page, it isn't happening. It gets stuck in the URL. My
> "onSuccess()" method does some further checking, and then returns. I
> get a huge URL. Does this not work from onSuccess?
>
> Norman Franke
> Answering Service for Directors, Inc.
> www.myasd.com
>
> On Jul 7, 2009, at 6:59 PM, Robert Zeigler wrote:
>
>> I haven't looked closely, but my impression was that T5's
>> @Persist("client") will encode the values to form fields when
>> there's a form present. I'm pretty sure that's what's intended...
>>
>> Robert
>>
>> On Jul 7, 2009, at 7/75:50 PM , Norman W. Franke wrote:
>>
>>> In the good old T4 days, I was able to persist form data between
>>> submissions without using any session state since the values were
>>> persisted in the fields themselves. This was very efficient,
>>> particularly for very large forms (with several text areas
>>> containing 50K of data each.) As a further bonus, any properties
>>> marked as "@Persist("client")" were stored in the form. This
>>> combined to make a very memory-efficient application suitable for
>>> clustering.
>>>
>>> Tapestry5 doesn't seem to allow this type of persistence, and
>>> clears all properties when refreshing the page. (i.e. returning
>>> null from an event handler.) This would seem to make T5 much, much
>>> less scalable for applications with significant amounts of data
>>> entry since one needs to persist the data in the session. A few
>>> 100K per session times 1000 or so sessions it a lot of RAM.
>>>
>>> So, I saw that T5 has a @Persist("client") strategy, but it doesn't
>>> appear to really be useful. It only stores the state in the URL. Is
>>> there a way to store it in the form? Clearly, this will only work
>>> if one has a form, but all my data entry forms will, obviously.
>>>
>>> Is there a solution to this dilemma? Right now, T4 looks much more
>>> efficient.
>>>
>>> -Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5 Persistence Question
Posted by Norman Franke <no...@myasd.com>.
On my page, it isn't happening. It gets stuck in the URL. My
"onSuccess()" method does some further checking, and then returns. I
get a huge URL. Does this not work from onSuccess?
Norman Franke
Answering Service for Directors, Inc.
www.myasd.com
On Jul 7, 2009, at 6:59 PM, Robert Zeigler wrote:
> I haven't looked closely, but my impression was that T5's
> @Persist("client") will encode the values to form fields when
> there's a form present. I'm pretty sure that's what's intended...
>
> Robert
>
> On Jul 7, 2009, at 7/75:50 PM , Norman W. Franke wrote:
>
>> In the good old T4 days, I was able to persist form data between
>> submissions without using any session state since the values were
>> persisted in the fields themselves. This was very efficient,
>> particularly for very large forms (with several text areas
>> containing 50K of data each.) As a further bonus, any properties
>> marked as "@Persist("client")" were stored in the form. This
>> combined to make a very memory-efficient application suitable for
>> clustering.
>>
>> Tapestry5 doesn't seem to allow this type of persistence, and
>> clears all properties when refreshing the page. (i.e. returning
>> null from an event handler.) This would seem to make T5 much, much
>> less scalable for applications with significant amounts of data
>> entry since one needs to persist the data in the session. A few
>> 100K per session times 1000 or so sessions it a lot of RAM.
>>
>> So, I saw that T5 has a @Persist("client") strategy, but it doesn't
>> appear to really be useful. It only stores the state in the URL. Is
>> there a way to store it in the form? Clearly, this will only work
>> if one has a form, but all my data entry forms will, obviously.
>>
>> Is there a solution to this dilemma? Right now, T4 looks much more
>> efficient.
>>
>> -Norman
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
Re: T5 Persistence Question
Posted by Robert Zeigler <ro...@scazdl.org>.
I haven't looked closely, but my impression was that T5's
@Persist("client") will encode the values to form fields when there's
a form present. I'm pretty sure that's what's intended...
Robert
On Jul 7, 2009, at 7/75:50 PM , Norman W. Franke wrote:
> In the good old T4 days, I was able to persist form data between
> submissions without using any session state since the values were
> persisted in the fields themselves. This was very efficient,
> particularly for very large forms (with several text areas
> containing 50K of data each.) As a further bonus, any properties
> marked as "@Persist("client")" were stored in the form. This
> combined to make a very memory-efficient application suitable for
> clustering.
>
> Tapestry5 doesn't seem to allow this type of persistence, and clears
> all properties when refreshing the page. (i.e. returning null from
> an event handler.) This would seem to make T5 much, much less
> scalable for applications with significant amounts of data entry
> since one needs to persist the data in the session. A few 100K per
> session times 1000 or so sessions it a lot of RAM.
>
> So, I saw that T5 has a @Persist("client") strategy, but it doesn't
> appear to really be useful. It only stores the state in the URL. Is
> there a way to store it in the form? Clearly, this will only work if
> one has a form, but all my data entry forms will, obviously.
>
> Is there a solution to this dilemma? Right now, T4 looks much more
> efficient.
>
> -Norman
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org