|
|
It's very common practice to have a consistent theme on a web site. You might have a standard navigation bar or a logo or even just a page footer with copyright and administrative information. Rather than actually having that information on each and every page it would certainly be nice if you could write your navigation bar once, keep it in one file, and then reference that file in each of several different pages. Make a change to the navigation bar in one place and instantly all pages are updated.
Welcome to "include" files - an incredibly powerful facility that can do this, and so much more, on your web site.
•
Includes break down into two categories: client and server. A "client" side include is one performed by your browser. Unfortunately, there is no specific syntax in HTML for client side includes so we have to play a small game using Javascript. A "server" side include is exactly that - the include happens on your web server so the client browser never even knows it happened.
Server Side Includes
We'll start with the conceptually easier one: the server side include. The specific syntax will vary based on what type of server you have and what your pages are written in.
Simple HTML pages on most common web servers can use a syntax called Server Side Include, or SSI. As an example in an HTML file a.html we can place this line:
<!--#include FILE="b.inc" -->
The page seen by a browser viewing a.html will consist of the contents of a.html before the include line, followed by the contents of b.inc, followed by the contents of a.html after the include line. Put the HTML for your navigation bar in a file like b.inc, and all your pages can show the exact same bar.
SSI is available on both Apache and Microsoft IIS web servers. On Apache some configuration may be needed but even if you don't have access to the actual server configuration files it can typically also be enabled by commands in a file named .htaccess that you will either find or can create in your server's web directory. Read more about Apache SSI here. Under IIS, SSI is enabled anytime you use ".ASP" pages -- so the only configuration you need do is to name your pages .ASP instead of .html. Read more about Server Side Include in ASP pages here.
Another popular ASP-like programming environment is php. php's include syntax is very simple:
<? readfile("b.inc"); ?>
Naturally, php has a host of additional processing ability but much like ASP the only requirement to make the include above work is to have php on your web server and name your file ".php".
With all of the above approaches, the browser viewing the page knows absolutely nothing about the include - it all happened before the page was downloaded. However, sometimes processing an include on the server isn't the right option. That's where processing an include on the client comes in.
Client Side Includes
As I mentioned above, there is no actual syntax for a client-side include but we can mimic one using Javascript. For example:
<script src="b.js" type="text/Javascript"> </script>
When encountered the browser downloads the script "b.js", executes it, and prints any output that the script might generate as if it were inline HTML. Technically that's not an include but the script "b.js" could be nothing more than a series of Javascript "print" statements such as these:
document.write("<table>")
document.write("<tr>")
... and so on
You can see it's "printing" the HTML you want included. In other words, if you can format your include file as a series of Javascript prints, you can use client-side include to insert it.
Now things can get very interesting, because we'll introduce two things: remote includes, and CGI programs, into the mix.
Remote Includes
The files we've included so far have been assumed to be on your own server in the same location as your other HTML pages. In almost all cases you can "include" using a full URL to any other server on the interNET.
For client-side includes it's very simple. It just works:
<script src="http://example.com/b.js" type="text/Javascript"> </script>
This works just like the earlier example execpt that b.js will get loaded from example.com rather than your own server. Similarly, php also "just works":
<? readfile("http://example.com/b.inc"); ?>
Unfortunately Apache SSI directives do not support remote includes. But there's almost always a way and we have a workaround using CGI.
CGI Includes
So far we've included only "static" HTML pages. As it turns out you can "include" the output of a server-run CGI program. This then becomes our solution for Apache's lack of support for remote includes. We'll start with this very short Perl program:
use LWP::Simple;
print "Content-type:text/html/n/n";
getprint ($ENV{'QUERY_STRING'});
We'll call it "proxy.pl". Proxy.pl must be appropriately installed on your server into your cgi-bin directory or its equivalent. By being local to your server Include directives can reference it.
Proxy.pl simply fetches the contents of URL passed as a parameter. This means we can perform an apache remote include this way:
<!--#include VIRTUAL="/cgi-bin/proxy.pl?http://example.com/b.inc" -->
It works like this:
The include executes proxy.pl with the parameter "http://example.com/b.inc"
Proxy.pl then fetches b.inc from example.com and prints it.
The result is that the contents of b.inc show up as an included file.
Includes + remote includes + CGI
So far we've used a CGI program to fetch what is essentially just another static html file. In fact, if we put all these pieces together we can create some very useful and interesting interNET applications.
Randy Cassingham of This is True wanted to be able to provide his readers who had web sites the ability to host one of his stories. Sounds like a job for an include file, right? But he also wanted that story to change every day. That's more than a static HTML page; that's a CGI program that outputs a different story each day.
The result is tad.pl (True-A-Day) - a Perl script that picks a new story every day and outputs HTML. Given what we've talked about so far so you can probably guess how it's used. As a client side include:
<script src="http://www.thisistrue.NET/cgi-bin/tad.pl" type="text/Javascript"> </script>
That's it in its simplest form. Note that:
tad.pl is written in Perl. It does whatever it needs to gather the HTML for the story to be output.
tad.pl outputs Javascript. In fact, tad.pl's output is nothing more than a series of "document.write" statements.
The client browser executes the Javascript. The result is that it prints the HTML that tad.pl constructed for today's story.
Using tad.pl in a server-side include looks like this:
<!--#include VIRTUAL="/cgi-bin/proxy.pl?http://www.thisistrue.NET/cgi-bin/tad.pl?ssi=1" -->
Note that as discussed above we had to use a local CGI program, proxy.pl, to fetch the remote URL.
Note also that we've added an additional parameter, ssi=1. This causes tad.pl to output the HTML it gathers without the Javascript document.write statements. The final sequence looks like this:
proxy.pl executes on your server, and is passed the URL "http://www.thisistrue.NET/cgi-bin/tad.pl?ssi=1".
proxy.pl fetches that URL, causing tad.pl to execute on www.thisistrue.NET.
tad.pl once again does whatever it needs to gather the HTML for the story to be output.
tad.pl outputs the HTML to be included.
That output is returned to proxy.pl, which in turn prints it, where it becomes the "included text".
The client browser sees nothing but HTML - the HTML from the containing page with the HTML from tad.pl inserted in place of the include statement.
As you can see, includes are not only a great organizational tool allowing you to collect common information into fewer files, but also a powerful way to add functionality to your web site and perhaps others. I'll end this with True-A-Day included via a client side include:
JavaScript技术：在html页面中包含共享页面的方法，转载需保留来源！
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
