[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tapestry-user
Subject:    Re: How to implement a FormCallback?
From:       Jon Millett <jon () millett ! net>
Date:       2004-10-29 16:43:54
Message-ID: 4182734A.5030206 () millett ! net
[Download RAW message or body]

Erik,
Thanks for the response.

>> Is there a way to create a Callback that results in a Form being 
>> reposted?
>
> Callbacks don't really re-submit though.

Nope. But it would be nice :-)

> One suggestion is to use persistent properties on the form, and simply 
> activate to that page. Or bundle up the form as parameter(s) to an 
> ExternalCallback.

I didn't want to have to resort to persistent properties. In addition, 
it doesn't help in this case because when a re-authentication is 
required, a PageRedirectException is thrown from within pageValidate( ) 
which is before the posted form has been rewound.

>> I have several protected pages with forms who's pageValidate( ) 
>> function periodically redirects them to a re-authentication page. I 
>> have been using a PageCallback to return from the authentication page 
>> to the orginal form. However, PageCallback doesn't record any form 
>> info and the user has to re-fill the form from scratch. I would like 
>> to have to have my authentication page be able to execute a 
>> FormCallback that reposts the orignal form if the re-authentication 
>> was successfull.
>
> Do you really need a re-post, as in directly from the client?

Not from the client, but from the form listener on the authentication 
page after a successfull re-authentication.

Out of curiousity I did the following as a test and it seems to work:

1) In the base page for my protected form pages. If re-authentication is 
necessary, I create a FormCallback( ) which saves the current request 
parameters.
2) Then the FormCallback is stored in a persistent property on the 
authentication page, and the authentication page is activated.
3) If authentication succeeds, the FormCallback's callback is performed. 
FormCallback's performCallback( ) method a) restuffs the request cycle 
with the parameters from the original form submit request b) activates 
the page of the original request, and c) throws a FormRedirectException 
which contains the form component from the original request.
4) A slightly modified version of DirectService's service() method then 
catches the FormRedirectException, extracts the target form component 
and calls its trigger(cycle) method.
5) The original form request is rewound. The end result is that even 
though the form submission was interuppted by the re-authentication, it 
still goes through and the user doesn't have to refill the form from 
scratch.

Any thoughts? It seems to be working in practice. Does it work in theory 
;-)? Am I missing any inherent problems?

Jon


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]