RE: Frames

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+). 

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? 

-J

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
>

Received on Tuesday, 2 May 2000 19:48:03 UTC