By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,851 Members | 1,051 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,851 IT Pros & Developers. It's quick & easy.

Data persistence and refresh

P: n/a
I have a piece of elearning where users move from screen to screen. The
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
Oct 27 '08 #1
Share this Question
Share on Google+
3 Replies


P: n/a
On Oct 27, 8:33*am, Andrew Poulos <ap_p...@hotmail.comwrote:
>
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.
Oct 28 '08 #2

P: n/a
On 2008-10-28 15:56, Jorge wrote:
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
Oct 28 '08 #3

P: n/a
Conrad Lender wrote:
On 2008-10-28 15:56, Jorge wrote:
>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.
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>
Oct 28 '08 #4

This discussion thread is closed

Replies have been disabled for this discussion.