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 <nor...@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-unsubscr...@tapestry.apache.org
>>>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>
>>>
>>
>
