Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #14755 > unrolled thread

Storage of quasi-static data across pages

Back to article view | Back to comp.lang.javascript

Contents

  Storage of quasi-static data across pages Stefan Weiss <krewecherl@gmail.com> - 2012-06-28 20:07 +0200
    Re: Storage of quasi-static data across pages "Tom de Neef" <tdeneef@qolor.nl> - 2012-06-29 15:49 +0200
    Re: Storage of quasi-static data across pages "Phil Hunt" <aaa@aaa.com> - 2012-06-29 10:23 -0400
    Re: Storage of quasi-static data across pages Scott Sauyet <scott.sauyet@gmail.com> - 2012-06-29 13:44 -0700
      Re: Storage of quasi-static data across pages Stefan Weiss <krewecherl@gmail.com> - 2012-06-30 04:03 +0200
        Re: Storage of quasi-static data across pages Scott Sauyet <scott.sauyet@gmail.com> - 2012-07-05 04:09 -0700
          Re: Storage of quasi-static data across pages Stefan Weiss <krewecherl@gmail.com> - 2012-07-06 00:36 +0200

#14755 — Storage of quasi-static data across pages

In a large web application (intranet only, reasonably modern browsers),
we have certain pieces of data which are created on the server and need
to be available to the client on every page. This includes, among other
things, a hierarchical menu structure and a list of message strings (not
hierarchical yet, but they will be).

The menu structure contains ~100 items and can be assumed to remain
static as long as the user's group membership and permissions don't change.

The messages include generic error messages ("Field %s does not contain
a valid date"), specific error messages ("If you do X on this page, you
also need to do Y."), as well as generic and specific status messages
and some informational text strings. These strings are shared between
the server and the client, because all form input is validated in both
places. There are ~500 messages for one language, totalling ~30k bytes.

We already have a mechanism in place to reduce the constant
re-transmission of menu and messages, but it's too complicated and not
entirely effective. Now the application is due for a complete
rewrite/redesign, and I was wondering about the best way to store that
data on the client between page loads.

The goal is to reduce network traffic, increase page load speed, and if
possible reduce the load on both server and clients.

Two main options come to mind: the browser cache and local storage. Both
will be available and enabled, and I can see both working equally well.

What are your opinions on which to prefer in the described environment?

- stefan

[toc] | [next] | [standalone]

#14762

"Stefan Weiss" <krewecherl@gmail.com> schreef in bericht 
news:jsi6hg$gfb$1@news.albasani.net...
> In a large web application (intranet only, reasonably modern browsers),
> we have certain pieces of data which are created on the server and need
> to be available to the client on every page. This includes, among other
> things, a hierarchical menu structure and a list of message strings (not
> hierarchical yet, but they will be).
>
> The menu structure contains ~100 items and can be assumed to remain
> static as long as the user's group membership and permissions don't 
> change.
>
> The messages include generic error messages ("Field %s does not contain
> a valid date"), specific error messages ("If you do X on this page, you
> also need to do Y."), as well as generic and specific status messages
> and some informational text strings. These strings are shared between
> the server and the client, because all form input is validated in both
> places. There are ~500 messages for one language, totalling ~30k bytes.
>
> We already have a mechanism in place to reduce the constant
> re-transmission of menu and messages, but it's too complicated and not
> entirely effective. Now the application is due for a complete
> rewrite/redesign, and I was wondering about the best way to store that
> data on the client between page loads.
>
> The goal is to reduce network traffic, increase page load speed, and if
> possible reduce the load on both server and clients.
>
> Two main options come to mind: the browser cache and local storage. Both
> will be available and enabled, and I can see both working equally well.
>
> What are your opinions on which to prefer in the described environment?
>

I would put the messages in a js file and trust that the browser will use 
its cache.
When the menu is fixed you can do the same with the menu structure (as xml, 
json or object definition).
Tom 

[toc] | [prev] | [next] | [standalone]

#14764

If you are using .net asp, you can store any object in the Session variable. 
You need to cast it to the type after you retrieve.

Or, use a DB

Or, store the information in an xml fragment in session variable



"Stefan Weiss" <krewecherl@gmail.com> wrote in message 
news:jsi6hg$gfb$1@news.albasani.net...
> In a large web application (intranet only, reasonably modern browsers),
> we have certain pieces of data which are created on the server and need
> to be available to the client on every page. This includes, among other
> things, a hierarchical menu structure and a list of message strings (not
> hierarchical yet, but they will be).
>
> The menu structure contains ~100 items and can be assumed to remain
> static as long as the user's group membership and permissions don't 
> change.
>
> The messages include generic error messages ("Field %s does not contain
> a valid date"), specific error messages ("If you do X on this page, you
> also need to do Y."), as well as generic and specific status messages
> and some informational text strings. These strings are shared between
> the server and the client, because all form input is validated in both
> places. There are ~500 messages for one language, totalling ~30k bytes.
>
> We already have a mechanism in place to reduce the constant
> re-transmission of menu and messages, but it's too complicated and not
> entirely effective. Now the application is due for a complete
> rewrite/redesign, and I was wondering about the best way to store that
> data on the client between page loads.
>
> The goal is to reduce network traffic, increase page load speed, and if
> possible reduce the load on both server and clients.
>
> Two main options come to mind: the browser cache and local storage. Both
> will be available and enabled, and I can see both working equally well.
>
> What are your opinions on which to prefer in the described environment?
>
> - stefan 

[toc] | [prev] | [next] | [standalone]

#14772

Stefan Weiss wrote:
> In a large web application (intranet only, reasonably modern browsers),
> we have certain pieces of data which are created on the server and need
> to be available to the client on every page.

> [ ... ] Now the application is due for a complete
> rewrite/redesign, and I was wondering about the best way to store that
> data on the client between page loads.
>
> The goal is to reduce network traffic, increase page load speed, and if
> possible reduce the load on both server and clients.
>
> Two main options come to mind: the browser cache and local storage. Both
> will be available and enabled, and I can see both working equally well.

I would definitely suggest the browser cache for this, especially if
you can use the collection of permissions, etc to generate a hash that
can be used in a url.  Combine these with some internal version
numbers and you can consistently generate the same urls for the same
users but quickly update the minute their permissions change.
Moreover you can simply update one of your version numbers any time
you want to invalidate the cache and force them to update.  It uses
the basic mechanisms of the web.  No one has to think twice about
implementation, and it's extremely simple.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#14778

On 2012-06-29 22:44, Scott Sauyet wrote:
> I would definitely suggest the browser cache for this, especially if
> you can use the collection of permissions, etc to generate a hash that
> can be used in a url.
...
> Moreover you can simply update one of your version numbers any time
> you want to invalidate the cache and force them to update.  It uses
> the basic mechanisms of the web.  No one has to think twice about
> implementation, and it's extremely simple.

I guess you and Tom are right. The browser cache already provides
everything I need. I think I was hoping I could finally use localStorage
outside of tests and mini-projects, but it's really unnecessary here. Ah
well, the day will come :)
(and we will be using session storage, at least)

About the versioning of cached content, I used that successfully in
other projects. It works great - you can easily invalidate the clients'
caches, and even deactivate caching completely (for testing). The app I
was talking about can't do it yet, but it will.

- stefan

[toc] | [prev] | [next] | [standalone]

#14865

Stefan Weiss  wrote:
> Scott Sauyet wrote:
>> I would definitely suggest the browser cache for this, especially if
>> you can use the collection of permissions, etc to generate a hash that
>> can be used in a url.
> ...
>
> I guess you and Tom are right. The browser cache already provides
> everything I need. I think I was hoping I could finally use localStorage
> outside of tests and mini-projects, but it's really unnecessary here. Ah
> well, the day will come :)

Well, if you want to really try out localStorage, have you thought
about making your application available off-line?  Is the data the
user last touched a good candidate to store for next time she logs in,
even if she's offline?  If so, then store another copy of all her
permissions and whatever data she is viewing and/or editing in
localStorage.  If she's offline, keep local edits there until she's
back online, and then save the changes back to the server.

It's both a fun and a frustrating exercise.  It should teach you a lot
about the possibilities and pitfalls of localStorage while adding a
real capability to your application.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#14887

On 2012-07-05 13:09, Scott Sauyet wrote:
> Well, if you want to really try out localStorage, have you thought
> about making your application available off-line?

Wish I could do that, but it's not that kind of application. The server
is the only data source (by design), and there are even mechanisms that
warn users when another user has recently been writing to the record
they're editing. There would be no point in storing some of the data
off-line.

> It's both a fun and a frustrating exercise.  It should teach you a lot
> about the possibilities and pitfalls of localStorage while adding a
> real capability to your application.

I can't wait - I like fun and frustrating :)
That's the pity when you mostly work in corporate environments. It's
still interesting, but they never have any use for the fun stuff. The
guy working next to me in our office buys a new gadget every few weeks,
because he actually needs them for his work. Lucky bastard. I'm stuck
with improving reliability for age-old technology.

- stefan

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web