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
