[11607] in www-talk@info.cern.ch
Re: Frames
daemon@ATHENA.MIT.EDU (Ari Gordon-Schlosberg)
Tue May 2 21:28:09 2000
Date: Tue, 2 May 2000 20:08:10 -0500
From: Ari Gordon-Schlosberg <regs@nebcorp.com>
To: www-talk@w3c.org
Message-Id: <20000502200810.A28529@nebcorp.com>
Mail-Followup-To: www-talk@w3c.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <9D7F61B87714D31194530090276212441F4259@outback.internal.outbackinc.com>; from jchalfan@outbackinc.com on Tue, May 02, 2000 at 04:52:31PM -0700
Resent-From: www-talk@w3.org
[Jay Chalfant <jchalfan@outbackinc.com>]
> Ari
>
> I believe it would be possible to accomplish without frames, everything I am
> doing now within frames. However, it wouldn't be easy (see Below) and
> wouldn't be worth the effort unless I had a specific requirement to do so.
> The web applications we develop are not targeted for public sites. They are
> internal IT assets. As such, we can list reasonable deployment requirements
> such as a modern, frames-capable browser (IE4+, NS4.5+).
Ahhh... ok, then! Yes, in the case where you have control over the client,
there's no real problem. See below for arguments against in public
internet.
>
> I know that many web developers shun frames. But apart from the concern of
> limiting broad public exposure, I don't understand the resistance. And even
> given that concern, it was my general impression (though not well informed
> since I don't develop public sites) that frames capable browsers are now the
> norm. If so, why the resistance to using frames?
It has to do with the range of browsers. Given all the possible
broswer/version/OS combos there are, you can potentially run into
showstopping bugs from differeing frames implementations. So the point is
to avoid that complexity when at all possible. however, I see from your
description below that your payoff is worth the complexity.
>
> Below:
> The level of functionality and amount of state stored in Java and JavaScript
> components in "constant" frames in our applications is not trivial. In order
> to maintain this state absent a constant frame I would have to:
>
> 1 - Serialize the state of all of the constant JavaScript components to a
> cookie and then restore them on every subsequent page load. I would probably
> end up developing some type of heirarchically organized structure on top of
> the cookie due to the depth and breadth of the data saved.
>
> 2 - To avoid Java Applet lifetime issues, I would have to move the
> intelligence out of applet instances and into static classes. Every page
> would still have an applet but it would serve only as a proxy for the static
> class-based service(s) in the VM. These services typically have a lifetime
> that exceeds a single page load. For example, a network connection that
> persists across page loads or a cache of retrieved values.
>
> 3 - I suspect that once I satisfied the basic state requirements for
> JavaScript and Java components via (1) and (2), I would still have to spend
> some effort tuning the timing characteristics of this relatively heavy page
> unload/load cycle.
>
> Bottom line: I would avoid (1), (2) and (3) if at all possible.
>
>
> > -----Original Message-----
> > From: Ari Gordon-Schlosberg [mailto:regs@nebcorp.com]
> > Sent: Tuesday, May 02, 2000 2:50 PM
> > To: Jay Chalfant
> > Cc: www-talk@w3c.org
> > Subject: Re: Frames
> >
> >
> > [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
> >
>
--
Ari there is no spoon
-------------------------------------------------------------------------
http://www.nebcorp.com/~regs/pgp for PGP public key
