Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Change Content In Div with Link (SSI?) 2

Status
Not open for further replies.

DBSSP

Programmer
Apr 1, 2002
327
US
Hi all. I'm designing an xhtml page and I'd like to be able to change the content inside the main Div (#Information) by clicking on a link in my menu. This way the whole page doesn't have to reload. If there is a way to do this using SSI, that would be cool. I already know I can include files, but I don't know how to change the include on the fly with a link. Perhaps there is a different way to do this other than SSI? I'm just trying to keep like text files for content and let the main xhtml document bring that info in and format it. Thanks for your help in advance!

Jay [infinity]
"If the words up and down were reversed, would you trip and fall or trip and fly?"
 
Can't imagine there being a SSI way to do it (at least without refreshing the page... and that wouldn't be SSI anyway). Are you counting on 100% compliability or is javascript an option?

--Chessbot

There is a level of Hell reserved for probability theorists in which every monkey that types on a typewriter produces a Shakespearean sonnet.
 
Hey Chessbot, thanks for the speedy reply.

I think javascript is about the only option to it at this point, the more I think about it. I'd like maximum compatibility, but then again I'd just hate to create redundant pages or hidden Divs to display simple content. Seeing as how most people browse with javascript enabled browsers, I don't see to much hurt becoming of using javascript. Any ideas about the script? Thanks again!

Jay [infinity]
"If the words up and down were reversed, would you trip and fall or trip and fly?"
 
Sure!

Can all of the content (unformatted) fit on the page or will it be too long?

--Chessbot

There is a level of Hell reserved for probability theorists in which every monkey that types on a typewriter produces a Shakespearean sonnet.
 
Each file of content will fit on one page in the div, but will be housed in their own independent files (i.e. Link One causes 1.html/txt to display in the div, Link 2 would cause 2.html/txt to display in the div, etc.). :)

Jay [infinity]
"If the words up and down were reversed, would you trip and fall or trip and fly?"
 
I mean would loading the contents of all the files into the page enlarge the page so much that it would be unable to download and the content must be refound each choice, or could you load all the files into the main page without taking up too much space?

--Chessbot

There is a level of Hell reserved for probability theorists in which every monkey that types on a typewriter produces a Shakespearean sonnet.
 
Well loading all the content files into the page would make it way too big, way too easy to get lost in. With that in mind I'm trying to keep the individual pieces of content remote, essentially treating the div likes it's own html page in a sense. (I thought about this in the "anchor" sense and found it too cumbersome.) If I could load all the files without too much drag, then that could work, but I'm trying to avoid the "hidden layer" syndrome and keep the load to a minimum on bandwidth so it'll be fast loading.

I know I'm being picky here, but it's tickling the back of my mind. The solution is there, I just can't quite grasp it.

Jay [infinity]
"If the words up and down were reversed, would you trip and fall or trip and fly?"
 
Is there no option to use Server Side Scripting, such as PHP or ASP here?

It is possible to create a page with a middle section that simply loads a different bit of code in based on a parameter passed in the URL of a link on the page.

Confused?

This is a REALLY old site, it isn't fully working as it's not in use anymore, but it will show the principle I mean.


With this site, the outer edges, top banner/menu and footer are hard coded into the page.
Each link in the menu takes the form of (for example)


A small bit of PHP in the middle of the index page pulls the corresponding file into the middle of index.php.
The length of the content does not matter as the design will scale (the left and right edges repeat).

It's dirty, and can be done MUCH more elegantly, but it works to demonstrate the principle.


- Web design and ranting
- Day of Defeat gaming community
"I'm making time
 
just use IFrames, they are not spider friendly but proposing to use javascript is even less so.

Code:
<a href="page1.htm" target="iframe_1">Page 1</a>
<br>
<a href="page2.htm" target="iframe_1">Page 2</a>
<br>
<a href="page3.htm" target="iframe_1">Page 3</a>
<br>
<a href="page4.htm" target="iframe_1">Page 4</a>
<br>
<br>
		
  <iframe id="iframe_1" name="iframe_1" width=600 height=200 src="page1.htm"></iframe>


Chris.

Indifference will be the downfall of mankind, but who cares?
A website that proves the cobblers kids adage.
Nightclub counting systems

So long, and thanks for all the fish.
 
If you're determined to follow this "Fix the menu and load the content in bits" approach, you might as well use (i)frames and have done with it. I don't see much point in reinventing the wheel with Javascript.

Whether you use real frames or ersatz-javascript-frames you'll still get the same disadvantages regarding accessibility and search engine visibility. Do you really want to saddle yourself with all that for the sake of a few K in bandwidth and a few fractions of a second in download time?

Use SSI, but do it the other way round - your pages contain (essentially) just the content, and you include the menu and other common page elements into them using SSI. Remember that external stylesheets and images will be cached by the browser, so the overhead of reloading such items on every page is not as big as you may think it is.

-- Chris Hunt
Webmaster & Tragedian
Extra Connections Ltd
 
RE Chris Hurst's answer:
<a href="page1.htm" target="iframe_1">Page 1</a>
<br>
<a href="page2.htm" target="iframe_1">Page 2</a>
<br>
<a href="page3.htm" target="iframe_1">Page 3</a>
<br>
<a href="page4.htm" target="iframe_1">Page 4</a>
<br>
<br>

<iframe id="iframe_1" name="iframe_1" width=600 height=200 src="page1.htm"></iframe>
---
My links will need to load content into two DIVs, rather than one iframe, and should run in IE5+ and NS6+, if possible. (I can specify newest browsers if necessary.) I have a solution that uses hidden iframes to hold the content and then copies the innerHtml from the iframe to the div, but that seems (a) cumbersome and (b) buggy (Flash animations handled this way seem to load but not run). The simple use of the "target" attribute seems like a good approach, but how to accomodate (1) use of DIVs (for CSS control) and (2) fill two targets at once? Thanks....

 
Further to my post earlier in this thread...

I would adopt ChrisHunt's approach if I were to build that 2ndSAS site again. Although it wasn't really a problem doing it, the more I thought about it afterwards the more I realised it was unnecessarily complex.

Making the Nav elements the include files is much more sensible.

Foamcow Heavy Industries - Web design and ranting
Toccoa Games - Day of Defeat gaming community
Target Marketing Communications - Advertising, Direct Marketing and Public Relations
"I'm making time
 
Wow! am I sensing some warming to framesets and iframes [dazed]. However, I do find it troubling when specious arguments are made over and over again without any supporting evidence.

Whether you use real frames or ersatz-javascript-frames you'll still get the same disadvantages regarding accessibility and search engine visibility. Do you really want to saddle yourself with all that for the sake of a few K in bandwidth and a few fractions of a second in download time?.

I have several framed sites and none of them ever have any trouble with search engines. If you google my tubularity site for example and click on the [ More results from tubularity.com ] link you will see that every page in the site has been googled appropriately.

Remember that external stylesheets and images will be cached by the browser, so the overhead of reloading such items on every page is not as big as you may think it is.

On early ie6 browsers the default option was to reload images on every page refresh. Even when this is not set the time to reload can be significant when the page is complex.

Here is a refresh type example. Without a frameset this would be too slow to be useful.




Clive
 
The link that I put in my previous post - sets out the disadvantages of frames better than I can. They have their uses, but my advice is to avoid them where you can.

If you do decide to use frames, then use frames. There's no point in all that faffing about with hidden frames and copying stuff across with Javascript - you'll still be stuck with the problems of frames, PLUS a dependency on Javascript for visitors to see any content (search engines won't see anything to index, for sure) PLUS browser incompatibility galore PLUS a whole heap of complexity in getting the thing to work in the first place.

Follow the KISS principle and keep it simple. Time that you're not spending constructing mountains of elaborate Javascript can be spent producing content. And that's what it's all about, right?

-- Chris Hunt
Webmaster & Tragedian
Extra Connections Ltd
 
Chris,

The link from:
is just the same old plagiarized drivel on framesets that can be found all over the web. It is as if the writers cannot be bothered to check the veracity of the words that they happily parrot.

In the first bullet point of the article the author says:
"the page is the atomic unit of information." Strange phrase, doesn't even sound reasonable, I wonder where that comes from... Google to the rescue.

1st hit:

oops here is another one:
This one at least, helpfully, indicates the apparent source of the quotation.

Oh wow! it's Jakob Nielsen's Alertbox for December 1996:
Why Frames Suck (Most of the Time).

1996 almost a decade ago in the previous millennium! To grasp how hopelessly out of date this is let us look at another section in Nielsen's article:

The November 1996 browser statistics from Interse show the following distribution of

browser usage:
Netscape 2: 13% of users
Netscape 3: 47% of users
Internet Explorer 3: 28% of users
Other browsers or earlier versions: 13% of users

Now if you try google-ing - "jakob nielsen"+1996+frames - you will get another raft of several hundred pages, some dated as late as 2005, slavishly quoting the same out-of-date nonsense.

Even Jakob himself, in Jakob Nielsen's Alertbox, May 2, 1999 says:
"Frames are no longer the disaster they were in 1995 and early 1996 due to some advances in browser technology:". Now he hardly ever talks about frames sic.(framesets).

Interestingly, it is quite amusing to see where he may have gotten the 'atomic' phrase.

Here the author says:
"The byte is inherently the atomic unit of information in HTTP."

In a similar way you can find hundreds of articles saying that framesets cause problems with search engines: SEO logic, a search optimization service, bravely asserts
that: "In fact, Inktomi and AltaVista simply won't index your framed site at all."

This is demonstrably untrue. Again try altavista-ing "tubularity". Inktomi was taken over by Yahoo.

Just as you don't care whether or not I use framesets, I don't care whether or not you do. My concern is for the newcomers to web development hearing this out of date stuff.

My advice would be for them to evaluate things for themselves.

For example, you can find another raft of articles saying that framesets cannot be used for PDA's. I decided to try it out and low and behold it actually turned out that framesets work incredibly well in the Blackberry. See: thread253-962240.

As far as your comments about Javascript, I do not know what you mean. Javascript or even server-side languages are not needed for framesets which is why they can be used locally without a web server.

I hope that you realize that my concern is for, unwittingly, perpetuating out of date information.









Clive
 
I really didn't want to reopen this stale debate here, but since you insist...

"Atomic unit of information" is a rather quaint phrase. Neilsen's talking about atomic in the philosophical sense of an atom being an indivisible particle. You might quibble with the choice of words, but the point still holds true.

If you were to look back at a lot of 1996-era design advice, I suspect you'd find a lot of it - likely the majority - singing the praises of frames. The fact that the information on today's sites is generally anti-frames could indicate that the world is made up of mindless parrots, or it could indicate that lots of people have tried frames, come up against their shortcomings, and rejected them. Old doesn't necessarily mean wrong, even on the web, though I agree there's a lot of bad, out of date advice out there - especially on SEO.

Competent search engines - such as Google - now make a good job of indexing framed sites, as your Tubularity results indicate. Where they struggle is in directing visitors to the page that's indexed. Either the user gets sent to a page that should really be inside a frameset - so it typically lacks navigation and maybe other important elements; or the get redirected to the top of the site (as, I think, happens in Tubularity) so they don't get to the page they want. If they do persevere long enough to find the right page, they can't bookmark it to get back to it.

It's minor irritations like this that rack up the case against frames. On the other side, there's much less to be said in their favour. They save you and your visitors a little bandwidth, they're one way of centralising common design elements, and they produce a visual effect that (until recently) couldn't be acheived otherwise. The last point was probably the biggest one in their favour, but with the recent advance of CSS2 it's no longer valid. Out-of-dateness of advice cuts both ways.

It's a free country. If you want to use frames, use them. If they work for you - fine. If you find that they're causing you (or your customers) problems down the line, don't come complaining to me. But for heavens sake, don't try and build some tottering Javascript halfway house. As Clive points out, search engines and browsers have fixed many of the problems once associated with frames - but you can reintroduce them by following the JS-heavy solutions proposed by some of the posters to this thread.

-- Chris Hunt
Webmaster & Tragedian
Extra Connections Ltd
 
Chris Hurst

I don't know whether I need to work on my writing or whether you need to work on your reading.

It was the "atomic unit" comment in the thread that Chris Hunt sent that helped me to identify where the author's 'opinion' was plagiarized from.

Like most of the frameset "opinions" to be found in articles on the web, they appear to be plagiarized from the same place, ie. Jakob Nielsen's 1996 article, "why frames suck (most of the time)".

Most of the problems that Jakob Nielsen described in 1996 are no longer problems and haven't been for a long time.

Search engines clearly and demonstrably do not have any difficulty spidering the frames as you seem to be indicating. Competent search engines (or maybe incompetent ones) do not struggle but simply send people to the page. The web developer can decide how to handle that.

The bookmarking problem is not considered by everyone to be a problem because it prevents deep-linking (the subject of recent lawsuits). Also it is easily remedied if one cared to do that.

I still don't know what you are referring to regarding "JS-heavy solutions". If you are referring to the mousepad link I included, the fact that it has javascript in it was not intended to be relevant. The point I was making was about whether refresh rates were fast in a complex page. My contention is that they are not.

There are many advantages to framesets which, in my opinion, far outweigh their disadvantages. Others are welcome to decide for themselves. They would be able to make a better decision if they did not receive so much inaccurate information from this forum by the "fear of framesets crowd".

I would point out that framesets are far more widely supported than any of the CSS or javascript work-arounds. Indeed innerhtml, for example, does not yet exist in any standard as far as I know.

Framesets are ideal also for distributing documentation that may never even see the web since frameset work locally without a web server. Although this is not documentation it does show the value of framesets in a book or manual application -
All I am challenging is bad information; otherwise I would not even be in this thread.

Kind regards,

Clive
 
Clive,
It's really hard to take a 'web professional' seriously when he has spelling mistakes on his home page.

________________________________________________________________
If you want to get the best response to a question, please check out FAQ222-2244 first

'If we're supposed to work in Hex, why have we only got A fingers?'

for steam enthusiasts
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top