Re: Destroying a page instance
Re: Destroying a page instance
- Subject: Re: Destroying a page instance
- From: Bill Reynolds <email@hidden>
- Date: Fri, 09 Apr 2004 08:46:36 -0700
Jonathan,
Maybe you've run across this, the setPageRefreshOnBacktrackEnabled worked to
solve the problem, but only on the dev platform - in production it didn't
change the behavior.
I even went so far as to subclass appendToResponse in the individual
components and disableClientCaching, but get the same results.
The problem I'm stuck on is that using a method in a component to create a
pageWithName works, but I can't get rid of the instance of that page
created. If I use the link and shoot it open in a "_new" window, then close
the window, then click the link again, the new window contains the same
pageWithName (as though it never went out of existence).
If I close the 'new' window, use a link on the page that takes me through
the request/response cycle again, then revisit the link that creates the
pageWithName I get the desired results (an newly instantiated page).
Isn't there some way to set the pageWithName to null or destroy it just
after instantiation?
Thanks for your previous responses,
-Bill
on 4/5/04 8:50, Jonathan Rochkind at email@hidden wrote:
> What's going on here is what's documented in WOApplication.
> setPageRefreshOnBacktrackEnabled.
>
> See that documentation; it's a bit confusing, but read it carefully
> and ask questions if you still don't understand. The default value
> for isPageRefreshOnBacktrackEnabled is true.
>
> You could just set this value to 'false' for your WO app. But I do
> not personally like that solution, the behavior documented there is
> often useful for _preventing_ a double invocation of an action method
> you _don't_ want called twice, when the user presses the browser
> refresh or back button.
>
> It would be nice if there were a way to set a particular action
> method to _not_ participate in the behavior we're talking about here,
> even though all other action methods would. Unfortunately, there's no
> way to do that. The only thing I can come up with is to use a direct
> action instead of a component action---direct actions are not
> effected by the behavior documented in
> setPageRefreshOnBacktrackEnabled. But it can be a pain to write a
> direct action when you really want a component action; but maybe it
> will work for you here (direct actions _can_ still have sessions
> associated with them).
>
> The basic thing here is: WO unfortuantely doesn't deal too well when
> you create multiple browser windows (or even frames, which amounts to
> the same thing). You can still do it (I do it myself), but you run
> into a variety of problems. Like the session page cache----click a
> bunch of times in one window, when you go back to the other window
> and click you're probably going to get a 'page expired from cache'
> message.
>
> --Jonathan
>
> At 6:20 AM -0800 4/5/04, Bill Reynolds wrote:
>> I'm using an action on a page to create a new page (in a new window). It's
>> a simple 'pageWithName' function, and that works fine.
>>
>> But, when the user closes the new window and clicks the link a second time
>> it doesn't work as expected. I would expect my method to create another
>> 'pageWithName' from scratch. But this only works if the user 'refreshes'
>> the initial page before clicking the link a second time.
>>
>> So how do I kill the new window/pageWithName instance so that the
>> action/link will only generate fresh instances each time?
>>
>> Thanks very much,
>>
>> -Bill
>> _______________________________________________
>> webobjects-dev mailing list | email@hidden
>> Help/Unsubscribe/Archives:
>> http://www.lists.apple.com/mailman/listinfo/webobjects-dev
>> Do not post admin requests to the list. They will be ignored.
> _______________________________________________
> webobjects-dev mailing list | email@hidden
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/webobjects-dev
> Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.