W3C home > Mailing lists > Public > www-talk@w3.org > May to June 2000

Re: Frames

From: Ari Gordon-Schlosberg <regs@nebcorp.com>
Date: Tue, 2 May 2000 20:08:10 -0500
To: www-talk@w3c.org
Message-ID: <20000502200810.A28529@nebcorp.com>
[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
Received on Tuesday, 2 May 2000 21:08:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:24 GMT