Re: [OT] Re: URL as UI
Re: [OT] Re: URL as UI
- Subject: Re: [OT] Re: URL as UI
- From: Jonathan Rochkind <email@hidden>
- Date: Thu, 21 Aug 2003 16:19:46 -0500
Hmm, I didn't anticipate any problems with re-awakening and sleeping
pages. There ought to be some way around that. But you've tried it, and I
haven't, so I believe you. I have done a bunch of playing around with
storing page instances and restoring pages for contextIDs for other
purposes, and never run into such problems. But maybe I've just never
noticed.
Obviously if you could avoid having to open your own seperate cache, that
woudl be a large improvement.
Alternately... to manage your own cache better and avoid memory leaks, you
could cache the contextID, and remove the WOResponse from the cache when
the contextID that generated it is removed from the session page cache.
Except this won't work, cause there's no way to know when a contextID is
removed from a page cache. That's something I've needed on several
occasions, and been unable to find a way to do. Hmm.
--Jonathan
At 10:44 PM 8/21/2003 +0200, you wrote:
Hi Jonathan,
You should write my javadocs:)
And you don't need to cache anything that isn't already cached by WO, or
worry about when it will be removed from the cache. All you're using is
the session cache and the session's page cache, there > already.
That's not quite true: you need to store the DA url (with session and
context id) as the key to the corresponding response in a cache, otherwise
you will run into a lot of trouble with re-awakened/sleeped pages. At
least I didn't get it to work with storing the pages, only with generated
responses.
But otherwise this is the way it works.
Cheers, Anjo
Am Donnerstag, 21.08.03, um 22:07 Uhr (Europe/Berlin) schrieb Jonathan
Rochkind:
I hadn't looked at Anjo's solution in some time. I guess I was
misremembering how it worked.
The solution I imagine, which is apparently different than Anjo's, is to
have each component define a method that returns a direct action URL that
is appropriate for that component, containing the neccesary state
information. /wa/SomeClass/viewWidget?widgetID=4&parentID=5 or what
have you. A true bookmarkable URL. If you wanted it to be fancy, you
could easily make it look something like:
/wa/SomeClass/viewWidget_4/parent_3 or something. As little information
as you need to reconstruct the page. A page with replace itself with a
redirect to such a URL in appendToResponse, unless it had been accessed
by such a URL.
You could put sessionID and contextID information on the end too, so if
the session is still there, you just get the page you already
initialized, no extra overhead but the roundtrip. But if the session
isn't there, you'd need to not throw a session expired, you'd just create
a new session---you have everything you need in the URL to recreate the
page from scratch. And you don't need to cache anything that isn't
already cached by WO, or worry about when it will be removed from the
cache. All you're using is the session cache and the session's page
cache, there already.
I'm sure there are more details, possibly significant ones, to be worked
out. But this overall design seems workable, to give you the flexiblity
of an application-server type environment (where you don't need to know
which page will be returned from a link at the point that link is
appended to response---that is decided later, upon the actual click),
with 'nice' URLs. It depends on a session; it wouldn't work for a
session-less app. But if you have a session-less DA app, you have easier
ways of making your URLs nice.
_______________________________________________
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.