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
