[11601] in www-talk@info.cern.ch
Re: Frames
daemon@ATHENA.MIT.EDU (Ari Gordon-Schlosberg)
Tue May 2 17:58:12 2000
Date: Tue, 2 May 2000 16:49:46 -0500
From: Ari Gordon-Schlosberg <regs@nebcorp.com>
To: Jay Chalfant <jchalfan@outbackinc.com>
Cc: www-talk@w3c.org
Message-Id: <20000502164946.B30504@nebcorp.com>
Mail-Followup-To: Jay Chalfant <jchalfan@outbackinc.com>, www-talk@w3c.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <9D7F61B87714D31194530090276212441F424C@outback.internal.outbackinc.com>; from jchalfan@outbackinc.com on Mon, May 01, 2000 at 10:39:15AM -0700
Resent-From: www-talk@w3.org
[Jay Chalfant <jchalfan@outbackinc.com>]
> There is another feature of frames that is even more important from our
> perspective. A web application may use a frameset that keeps one of the
> frames loaded throughout the application session. This "constant" frame is
> the only place to store persistent Java and JavaScript components. These
> components are then used by other frames in the frameset that change as the
> user navigates through the application.
>
> The ability to store complex state on the client in a convenient and
> seamless fashion is a cornerstone of our approach to building web
> applications. I'd hate to see this go away.
Instead of playing tricks with the browser, why not use some http-builtin
state management mechanism, like cookiees and then use a back end for
persistence?
--
Ari there is no spoon
-------------------------------------------------------------------------
http://www.nebcorp.com/~regs/pgp for PGP public key
