tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jakarta-tapestry Wiki] Update of "WishList" by ThijsSuijten
Date Wed, 06 Apr 2005 10:33:07 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-tapestry Wiki" for change

The following page has been changed by ThijsSuijten:

+ ThijsSuijten: Wouldn't it be nice to once and forever get rid of "back" "forward" and "refresh"
hell while developing a web application?
+ I've been reading the following article that provides an easy but effective solution for
the back/foward/refresh problem. It would be VERY nice if this solution could be implemented
in Tapestry Framework to get rid of the back/foward/refresh problem forever!
+ http://www.theserverside.com/articles/article.tss?l=RedirectAfterPost
+ I already use the "form submit synchronization token", sure it solves the unsynchronized
state of my application but it doesn't work intuitively for our users. I even (who build the
web application) sometimes accidentally press the back button... 
+ I think the there are two options: 
+  * Redirect immediately: in the RedirectService (something like DirectService) a redirect
immediately takes place and all parameters must be copied into the session Object, the service
which is redirected to must read and discard these session parameters and rewind the request.

+  * Redirect formSubmit: The rewind cycle takes place as usual, at the end of the rewind
phase a redirect is triggered. No parameters have to be stored in the session Object because
the rewind phase was responsible for processing/persisting the parameters. 
+ The second option can already be used manually to realize the PRG pattern. For example:

+ {{{
+    public void submitForm(IRequestCycle cycle) { 
+        PageService s = new PageService(); 
+        String redirect = s.getLink(cycle, this, new Object[]{"GetPage1"}).getURL(); 
+        throw new RedirectException(redirect); 
+    } 
+ }}}
+ Instead of: 
+ {{{
+    public void submitForm(IRequestCycle cycle) { 
+        cycle.activate("GetPage1"); 
+    }
+ }}}
   * Add support for components that use XMLHttpRequest.  XMLHttpRequest (or something similar)
is supported by Microsoft, Mozilla, Safari, and Opera.  Basically, Javascript can request
information from the server and update a portion of a page rather then refreshing the whole
page.  An example of a component that could benefit from this would be a derivative of the
DatePicker component that could be used for scheduling appointments.  As the user selects
a month, the "already reserved slots" could be retrieved from the server to update the component.
 While it is not strictly necessary for Tapestry to govern the conversation between the component
and the server, there are many benefits in doing so.  For example, if the client's browser
does not support XMLHttpRequest it will be necessary to refresh the entire page, and Tapestry
would definitely handle that task.
   * How about a Tapestry Context? I've built one for our projects, it sets the Visit into
ThreadLocal. This way, helper classes don't have to pass around the Visit. The extended BasePage
implements IPageListener and sets (and unsets) the Visit. Classes that control web flow can
grab it themselves. You could also put HttpRequest in it for implementing Portal support (this
was mentioned in HLS's post as problematic). Probably all of a 30 minute job.
View raw message