Data persistence and refresh
Andrew Poulos
content itself is displayed within an IFRAME with the parent window
containing the various navigation controls and javascript.
I did it this way because there's a substantial amount of javascript
that gets loaded and a significant amount of data that gets created as
the user moves about the lesson.
All seems well and good until the user refreshes the screen. Then all
the various objects are initialised and the data tracking gets trashed.
I tried using single pages where the data gets written to cookies but:
- I'm unsure it will handle the amount of data a user may generate
- There's a 5+ second lag as the screen clears and is rebuilt between
clicks on the "next" button. Here I thought that the scripts, navigation
elements, background images would be cached and so would not be a
problem but this does not appear to be the case.
Is there a "good" way to have a site that consists of many pages where a
large amount of data is accumulated as the users moves about the site
but is not lost if the user refreshes the page?
Andrew Poulos
Jorge
>
> Is there a "good" way to have a site that consists of many pages where a
> large amount of data is accumulated as the users moves about the site
> but is not lost if the user refreshes the page?
>
> Andrew Poulos
Not client-side storage. Not yet. Persistent client-side storage
(nowadays) can only be achieved cross-browser by cookies. And cookies
aren't a good solution because they have a length limit (~4k ISTM),
and what's worse, the info that you put into a cookie gets sent in the
headers of each and every request to that domain, unless you carefully
adjust/plan the paths of both the cookies and the requests that you
make.
The future will hopefully bring other persistent client-side storage
solutions. Safari already implements both the "localStorage" api of
the whatwg html5 proposal: <http://www.whatwg.org/specs/web-apps/
current-work/#the-localstorage-attribute>, and the persistent SQL-
client-side database storage api <http://www.whatwg.org/specs/web-apps/
current-work/#sql>. IE has other things of its own, activeX controls
or something I think.
So, given the situation, for large amounts of data, you'd probably
better save session state/data server-side, and use a light-weight
client-side cookie as a session id.
--
Jorge.
Conrad Lender
> So, given the situation, for large amounts of data, you'd probably
> better save session state/data server-side, and use a light-weight
> client-side cookie as a session id.
Yes, that's probably the best advice in this situation. Just for the
record, it's possible to store pretty large amounts of data using Flash.
Depending on the setup the same data store could even be available from
different browsers.
- Conrad
Swifty
> So, given the situation, for large amounts of data, you'd probably
> better save session state/data server-side, and use a light-weight
> client-side cookie as a session id.
Absolutely. Of course, you run into problems with the user who blocks
cookies, or who uses different browsers (which each have their own
cookie storage, unfortunately).
If you have the luxury of authentication (i.e. the user has to sign on
with an ID/password) then that is probably better.
--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk
Thomas 'PointedEars' Lahn
Flash isn't necessary, some recent browsers provide Storage and friends.
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>