tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <e...@ehatchersolutions.com>
Subject Re: solving reload
Date Wed, 30 Mar 2005 01:02:15 GMT
On Mar 29, 2005, at 6:54 PM, Jamie Orchard-Hays wrote:
> Right, that seems like the main stumbling block. I know Erik's been  
> messing with this a bit.
>
> Erik, didn't you write some sort of custom component recently to deal  
> with this?

Didn't read all of the posts from me recently, eh?!  :)

Yes, I have a custom service and link that redirect after invoking a  
listener method.  It's basically a replacement for DirectLink.  At the  
moment it only redirects to the page (as a PageLink), so there is no  
parameter handling.  I will, when my application demands it, extend  
this so that parameters can be passed, and perhaps even specify the  
page.  The parameters would be passed in the URL like an ExternalLink  
(or a custom one that names the parameters is more likely).

As Howard mentioned, this has some disadvantages, such as state being  
lost unless it is passed on the URL.  For example, if you do a redirect  
after a form submit you wouldn't be able to (easily) show all the  
validation errors as that information is transient for the lifetime of  
the request.

I'm not completely satisfied with what I've create thus far - the main  
negative at the moment is that it doesn't work with @Form (and maybe it  
shouldn't for the reason given above) - or at least it might need to be  
smart and not redirect if there are validation errors.

If you have some ideas on how to make this more built-in, I'm all ears!

	Erik



>
> Jamie
>
> Howard Lewis Ship wrote:
>
>> The only reason Tapestry doesn't do this today, because it is
>> desirable, is because you often need some transient data that will be
>> lost between requests.
>>
>> I'm seeing this with the JSR-168 stuff which strongly enforces this
>> pattern ... you start having to make more properties persistent.
>>
>>
>> On Tue, 29 Mar 2005 18:48:04 -0500, Jamie Orchard-Hays  
>> <jamie@dang.com> wrote:
>>
>>> My basic thought is that it shouldn't be a pattern. It should be  
>>> built in.
>>>
>>> Jamie
>>>
>>> Mark Stang wrote:
>>>
>>>
>>>> Which is similar to this:
>>>>
>>>> http://www.theserverside.com/articles/article.tss? 
>>>> l=RedirectAfterPost
>>>>
>>>> I read through the article, but haven't analyzed it in detail.
>>>>
>>>> regards,
>>>>
>>>> Mark
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Jamie Orchard-Hays [mailto:jamie@dang.com]
>>>> Sent: Tue 3/29/2005 4:09 PM
>>>> To: Tapestry development
>>>> Subject: solving reload
>>>>
>>>> I came across this article today comparing WEE and Rails and thought
>>>> this would be food for thought here:
>>>>
>>>> Imagine you look at a simple Wee application which displays an HTML
>>>> anchor tag. If you click on that anchor, you'll trigger an /action
>>>> phase/, which eventually will find the registered callback  
>>>> associated
>>>> with the anchor you have clicked on and invokes it. At the end of  
>>>> the
>>>> /action phase/, Wee will forward you to a new (automatically  
>>>> generated)
>>>> URL, which when requested by your browser, will trigger the /render
>>>> phase/. This in turn renders the whole component tree. "Why  
>>>> redirect",
>>>> you might ask. Well, this simply avoids that the same callback will  
>>>> be
>>>> invoked again if you hit your browsers reload button. Whenever you  
>>>> hit
>>>> on reload, this will only trigger a /render phase/ event.
>>>>
>>>> From:
>>>> http://www.artima.com/forums/flat.jsp?forum=123&thread=96454
>>>>
>>>> This would certainly be desirable behavior in Tapestry. I know  
>>>> there was
>>>> some recent discussion about this, though I was a bit out of things  
>>>> for
>>>> the past few weeks.
>>>>
>>>> Thoughts?
>>>>
>>>> Jamie
>>>>
>>>> -------------------------------------------------------------------- 
>>>> -
>>>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail:  
>>>> tapestry-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


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


Mime
View raw message