Same table, different pages

[Brian]

its not all about where a link takes you but what you can do with it.
for example right clicking on the current page link to open it in
the background to keep it for later while you continue to surf the
site on the page already open.

We may be able to do additional things with a link in our favorite
browsers, but the primary purpose of a hyperlink has been to provide a
jumping off point to another web resource. I'd have to agree with Neal,
it makes no sense to provide a link in the current resource to itself.
And on a practical note, it might confuse true newcomers to the web.

my problem is i'm used to using my browser a certain way but now
you've killed off the current page link so i'm forced to use another
unfamiliar method (if one is available) to do whatever i wanted to do
with the link.

Your argument rests on the assumption that a link in a document to
itself is natural. I don't accept that assumption.

 

[brucie]

in post: <

Do you complain when the waitress brings you a soda without a straw, as
some drinkers cannot drink without one?

no but i get really pissed off if it hasn't got a cute little umbrella.
doesn't everyone?

 

[Duende]

While sitting in a puddle Mark Tranchant scribbled in the mud:

I use PHP for this. The menus at http://tranchant.plus.com/ are
generated with one file per directory, and each "HTML" page calls a menu
function to draw the menus and define which are the active items for
highlighting.

Would you be willing to share your PHP menu code with us lesser types?

 

[Alan J. Flavell]

A good start. But, imho, if you're going to dabble in php (or some other
page that interfere's with caching), you ought to go the full 9 yards
and parse the request headers for if-modified-since and if-none-match,
and return 304 as appropriate.

It's a fine idea, but it sounds a lot of work. I'd prefer the
scripting system to handle this on my behalf, when I wanted it - e.g
via some kind of option setting.

Disclaimer: my detailed knowledge of PHP is rather minimal.

Alternatively, as I said before, maybe - when essentially "static"
pages are built from components - it would be better to do the
building behind the scenes, whenever the component(s) are changed (e.g
with a makefile and some kind of offline processor), and leave the
HTTPD to do what it already does extremely well - serving out static
pages in accordance with the rules of HTTP, with ETag and if-modified
support and all.

But in the end it's not up to me to choose - I'm just trying to coax
folks into keeping some semblance of cacheability when it's
appropriate.

cheers

 

[Brian]

It's a fine idea, but it sounds a lot of work.

You're right about one thing: it's a lot of work. I spent a couple of
days on it last week, and thought I had it figured out, but I can't seem
to get it to send 304.

I'd prefer the scripting system to handle this on my behalf, when I
wanted it - e.g via some kind of option setting.

Disclaimer: my detailed knowledge of PHP is rather minimal.

I'm pretty new to it, but I don't think there's any option setting to
let it do it on its own, for the same reason that no such setting exists
with ssi: the php script has no way of knowing what the last-modified
date is.

maybe - when essentially "static" pages are built from components -
it would be better to do the building behind the scenes, whenever the
component(s) are changed (e.g with a makefile and some kind of
offline processor)

I think that is probably best, when possible. I've found offline
preprocessors woefully inadequate, though, so I don't know how practical
that advice is for authors.

 

[Dirk Bruere at Neopax]

We may be able to do additional things with a link in our favorite
browsers, but the primary purpose of a hyperlink has been to provide a
jumping off point to another web resource. I'd have to agree with Neal,
it makes no sense to provide a link in the current resource to itself.
And on a practical note, it might confuse true newcomers to the web.



Your argument rests on the assumption that a link in a document to
itself is natural. I don't accept that assumption.

Well, jumping back in again, I wanted a simple *universally applicable* method
of having *one* nav table on all pages. It seems it cannot be done simply.
So, all I intend to do is an automated cut and paste from a text editor
(including a URL to the current page). It may or may not be 'natural' but it's
legal in all browsers.

--
Dirk

The Consensus:-
The political party for the new millenium
http://www.theconsensus.org