Alternative to frames!

[Richard]

In an in-house ASP site (designed to support IE5.5+ and NN7+) we are using
frames today and I know there are several issues by using frames but I
cannot see a better alternative.

In one frame I have a treeview. This treeview is not static (if the user
clicks on a node it will expand/collapse). It is different for every user.
It is pretty heavy to load. The main frame is loaded every time the user
searches for data etc (which occur often) but the treeview frame is only
reloaded when the user is actually working (clicking) on the treeview.

If I remove the frames I would have to run the pretty heavy code for
building up the non-static treeview for every page (which includes
instantiating COM+ component and database access etc) and this will be
much slower than it is today (at least when I tested). The users want to
see the treeview all the time because they are familiar with that in the
windows client (otherwise a link to a page that shows the treeview could
be an alternative).

This is an in-house site and issues with frames like bookmarking, indexing
etc is not an issue in this case. I don't actually have any problems with
the frames today and the small tests I have done with server side includes
did not perform well.

Is this just an unusual case where frames are the best choice or what
alternatives do I have? I prompted for removing the treeview (and also a
calendar frame) which are used rarely and add links that would open the
page with the treeview/calendar but they insisted that they should be
visible all the time.

Regards
/Hans

A simple two column division setup would work just as well.
Set up the page as a css file and call it when ever you need to change
pages.
You could also use "iframe" in the second column as if the page were a
regular frame set.
Since it's in-house, who else cares?

 

[Jeffrey Silverman]

I think the guys who propagate php stop a little bit to soon proudly showing
their efforts.

Huh?

 

[Jeffrey Silverman]

As you said I don't have any big problems today and the end users don't care
if I use frames or not. They just want a system that works. I was just
curious if I was to start over from scratch today would I still stick to
frames?

The problems with frames relate more to the lack of control that most web
designers ultimately have of the end-user's environment. It sounds like
your end-users are in a relatively predictable environment. So if frames
are working for you, then use 'em.

 

[Duende]

While sitting in a puddle jake scribbled in the mud:

Frames are your friends ;-)

Waaaaaa, copyright infringement.

 

[Toby Inkster]

In one frame I have a treeview. [...] It is pretty heavy to load.

As it is an intranet, and assuming all clients have Javascript available,
create a script called treemenu.js like this:

------------------------------------------------------------
function createmenu () {
var menu = "";
menu = menu + '<ul>';
menu = menu + '<li><a href="home">Home</a></li>';
// etc
menu = menu + '</ul>';
document.getElementById('menu').innerHTML = menu;
}
window.onload = createmenu;

 

[Mark Parnell]

Waaaaaa, copyright infringement.

Talk to Mir - she deals with people saying "meh"[1] all the time.

[1] TM Mir (SpaceGirl)

 

[nice.guy.nige]

While the city slept, Jeffrey Silverman ([email protected]) feverishly
typed...

Huh?

You took the word right out of my mouth! ;-)

Cheers,
Nige

 

[Philip Ronan]

While the city slept, Jeffrey Silverman ([email protected]) feverishly
typed...


You took the word right out of my mouth! ;-)

Cheers,
Nige

I think Jan has a point.

There is hardly a single PHP page out there that implements the HTTP specs
as well as a plain HTML text file of the sort you normally find used in a
frameset. In fact most PHP pages don't conform to the HTTP specs at all.

Here's a challenge: can anyone show me a PHP page that ...

a) Knows how to respond correctly to all the HTTP/1.1 request types
(OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE and CONNECT) without just
sending back the same HTML content every time, and

b) Generates Content-Length and ETag headers that allow proxy servers and
clients to cache the page properly?

I think probably not.

But plain old vanilla HTML pages of the type you normally find in framesets
can do all of these things because nobody's bothered to meddle around with
them in PHP.

I'm not defending frames, by the way. I'm just pointing out that it takes
more than "simple" SSI techniques to solve their problems.

 

[Mark Parnell]

I think Jan has a point.

You mean you understood it? That sentence didn't make much sense to me,
and apparently it didn't to Jeffrey or nige either.

 

[Toby Inkster]

Here's a challenge: can anyone show me a PHP page that ...

a) Knows how to respond correctly to all the HTTP/1.1 request types
(OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE and CONNECT) without just
sending back the same HTML content every time, and

Show me an HTML page that does!

PHP can cope, by default, with GET, POST and HEAD which are *by far* the
most common HTTP requests. The others are pretty much synonymous with
hacking attempts when it comes to a normal website.

b) Generates Content-Length and ETag headers that allow proxy servers and
clients to cache the page properly?

I've done a Perl script that generates proper Content-Length and ETag
headers (and Last-Modified). Close enough?

 

[Philip Ronan]

Show me an HTML page that does!

Apache servers seem to do quite a good job when left to their own devices.

PHP can cope, by default, with GET, POST and HEAD which are *by far* the
most common HTTP requests. The others are pretty much synonymous with
hacking attempts when it comes to a normal website.

PHP? What about conditional requests and headers like ETag, Last-Modified,
and Content-Length? By default, PHP provides a very skinny implementation of
HTTP while making pages uncacheable and eliminating support for conditional
and partial fetches.

I've done a Perl script that generates proper Content-Length and ETag
headers (and Last-Modified). Close enough?

So why aren't you using this on your home page? And what are all those
anti-cache headers doing there? Are you determined to make your site run
slower?

 

[Steve Pugh]

Here's a challenge: can anyone show me a PHP page that ...

a) Knows how to respond correctly to all the HTTP/1.1 request types
(OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE and CONNECT) without just
sending back the same HTML content every time, and

I don't know about some of those, but my PHP pages handle If Modified
Since requests properly (returning 304 as appropriate) which seems to
me to be something lacking in most PHP pages.

b) Generates Content-Length and ETag headers that allow proxy servers and
clients to cache the page properly?

Yep. Doing that. See http://www.sfsfw.net/index.php

(I'm current reconsidering the must-revalidate value for
cache-control, my initial reading of the spec suggested that it was a
good thing - I'm supplying useful expires and max-age info and so the
must-revalidate should only apply if the cached document is stale, but
the latest upgrade to Opera is now revalidating under all conditions,
so maybe I've misunderstood RFC 2616.)

I think probably not.

I'm only a beginner with PHP but this was on of the first things I
worked out how to do. Maybe I'm coming at PHP from a different angle
to most people. I agree that PHP could do better by default and that
most PHP programmers are ignorant of these issues. But let's not
single out PHP, ASP and all the others seem to be as bad.

Steve

 

[SpaceGirl]

Waaaaaa, copyright infringement.

Talk to Mir - she deals with people saying "meh"[1] all the time.

[1] TM Mir (SpaceGirl)

hheheeh

--


x theSpaceGirl (miranda)

# lead designer @ http://www.dhnewmedia.com #
# remove NO SPAM to email, or use form on website #

 

[kchayka]

That sentence didn't make much sense to me,

There have been many occassions when Jan's posts were confusing to me,
to say the least. This one sounds much like a machine translation.

 

[Toby Inkster]

So why aren't you using this on your home page? And what are all those
anti-cache headers doing there? Are you determined to make your site run
slower?

Touche. Mainly because of the style switcher.

The pages themselves are generally fairly small (10KB-20KB for most) and
all the images, CSS and scripting can be cached, so I think there is not a
huge amount to be gained by making everything cachable.

It is something I'm thinking about though.