|
Posted by Corey Walker on October 22, 2007, 2:16 am
Please log in for more thread options
> Look into server-side includes.
> http://allmyfaqs.net/faq.pl?Include_one_file_in_another
>
Back in 1997, when I was first learning very basic HTML, we had some
pages in the Counselling Centre at the University of Northern BC (where
I was working at the time as a student) that used SSI. Unfortunately, my
co-worker was selected to be taught how to do SSI, and I wasn't. I will
have to find out if my web server supports SSI. It does support cgi
scripts, so it probably would support SSI.
How difficult are server-side include, PHP or ASP to learn? The latter
two are very commonly used these days, but I don't know how complicated
they are.
Corey
|
|
Posted by John L. on October 22, 2007, 6:15 am
Please log in for more thread options
Corey Walker wrote:
>
>> Look into server-side includes.
>> http://allmyfaqs.net/faq.pl?Include_one_file_in_another
>>
> Back in 1997, when I was first learning very basic HTML, we had some
> pages in the Counselling Centre at the University of Northern BC (where
> I was working at the time as a student) that used SSI. Unfortunately, my
> co-worker was selected to be taught how to do SSI, and I wasn't. I will
> have to find out if my web server supports SSI. It does support cgi
> scripts, so it probably would support SSI.
>
> How difficult are server-side include, PHP or ASP to learn? The latter
> two are very commonly used these days, but I don't know how complicated
> they are.
I highly recommend learning PHP, even if you only learn the basics, as
even a little bit of server-side scripting can go a long way.
You mentioned having the links all in once place for easy maintenance.
This is easy in PHP. Simply create a file with nothing in it but the
navigation (links.html), then, whereever you want the links to appear in
your web pages, just include it with PHP:
<div id="navigation">
<?php include('links.php'); ?>
</div>
The resulting page will look exactly as if the links were typed directly
into the source.
Does your current web host support PHP? If not, it's easy to find one
that does.
|
|
Posted by John L. on October 22, 2007, 6:17 am
Please log in for more thread options John L. wrote:
<snip>
> You mentioned having the links all in once place for easy maintenance.
> This is easy in PHP. Simply create a file with nothing in it but the
> navigation (links.html), then, whereever you want the links to appear in
^^^^^^^^^^
> your web pages, just include it with PHP:
>
> <div id="navigation">
> <?php include('links.php'); ?>
> </div>
Sorry, my file names don't correspond. But you get the idea ;)
|
|
Posted by André Gillibert on October 22, 2007, 4:56 pm
Please log in for more thread options John L. wrote:
> I highly recommend learning PHP, even if you only learn the basics, as
> even a little bit of server-side scripting can go a long way.
>
> You mentioned having the links all in once place for easy maintenance.
> This is easy in PHP. Simply create a file with nothing in it but the
> navigation (links.html), then, whereever you want the links to appear in
> your web pages, just include it with PHP:
>
> <div id="navigation">
> <?php include('links.php'); ?>
> </div>
>
Server side scripts are great. They're useful and quite transparent to the
end user.
But, server side scripts have drawbacks that must be weighted against
their benefits when compared to alternative reliable authoring strategies.
They're not obvious at first sight, but these drawbacks are real. They
negatively impact the server and the end user.
Server side scripts for extremely dynamic content, likely to change every
few seconds or depending on form requests (e.g. search features) are
perfectly fine.
But for static pages for which server side scripting would be used for
maintainance purposes, they've tradeoffs:
1) HTTP cache control. For example, conditional GET operations will always
think that documents have been changed and reload them.
This has a simple effect with most user agents: Everytime you navigate to
a page of the site, it's entirely reloaded (except for the back history,
with good browsers).
With static content, a conditional GET is performed (with good user
agents), which requires very small network resources, and returns a small
header indicating that the resource hasn't been changed. This greatly
reduces the client and server bandwidth used. If an adequate expiration
header is set, this conditional GET request can even be saved, sometimes!
In addition, if you use a HTTP proxy, it can cache the request.
This is useful for the end user if he has a better ping and bandwidth with
his HTTP proxy (e.g. ISP provided proxy) than with your server (this used
to be very true in the 1990's, but becomes less important nowadays). These
proxy will also reduce the number of requests to your site, especially if
it's very popular.
The HTTP cache control mechanism is really subtle. A large part of
RFC-2616 deals with it. Dynamic pages break that.
2) Typically, the server don't send a compressed stream for dynamic
resources even if the user agent declares a Accept-Encoding header
including gzip, compress or other compression algorithms.
Compression can reduce by 3 or 4 the file size! Both the server and client
benefit from this!
3) HTTP 1.1 partial downloading is very unlikely to work with dynamic
content. This does matter for big files only. Below 400 kilobytes, it's
not very important.
4) The Content-Length attribute won't be specified, though it can help the
user agent. e.g. User agents use it to display a progress bar and
automatically, or with user help, they may choose to stop downloading the
resource if it's too large or to use an alternative download manager.
Actually, the HEAD method looses of its usefulness if the Content-Length
attribute disappears.
Other minor detail: The Content-MD5 won't be provided while it could be
useful on unreliable connections.
Overall, I've always had a better browsing experience with static pages
than with dynamic pages thanks to the reduced and removed loading delays
Fortunately, it's possible to get a good authoring system, and yet,
benefit from static pages for pages that don't change every second.
There are several solutions.
The first one, is to write scripts (e.g. PHP programs) that generate files
and store them in appropriate places, with appropriate configuration
files, on the server.
Then, when things are modified, a master script would be launched. It
would simply generate all the pages from the scripts.
The second one is similar, but doesn't use scripts. It uses the SGML
authoring capabilities.
It's less powerful, but is sufficient is all you need is SSI and a good
management and versioning of individual files.
To do so, a tool is needed: An SGML normalizer. Ideally, it should be
configurable to normalize only what's required. For example, it should
expand entity references and marked sections (because they're not
supported by existing HTML user agents), but shouldn't close omitted tags.
The spam utility of SP is a good choice:
http://www.jclark.com/sp/
The HTML files would contain an document type definition defined by an
external and/or internal declaration subset.
Entities would be defined in external files shared by all the HTML
documents, or in the internal declaration subset. With OASIS catalogs, the
file management should be easy.
After having modified one or more file, you would just have to launch a
script applying the normalization to all the HTML files, and storing the
resulting files in the server directory.
That's a very simple batch job.
To benefit from this good authoring tool, you've to learn the basics of
SGML. As a HTML author, knowing SGML is a good thing.
The following site is a good introductory to SGML:
http://www.is-thought.co.uk/book/home.htm
Maybe I'll start a debate around server side scripting... I'm sure we
could learn more about the benefits and tradeoffs of server side scripting
with the insights of experts.
--
If you've a question that doesn't belong to Usenet, contact me at
|
|
Posted by Chris Morris on October 22, 2007, 6:29 pm
Please log in for more thread options > John L. wrote:
> > I highly recommend learning PHP, even if you only learn the basics,
> > as even a little bit of server-side scripting can go a long way.
Although, it's too easy to write insecure PHP once you go past the
very basics. As long as you stick to include('filename'); and don't do
anything with variables it should be safe, though.
> But for static pages for which server side scripting would be used for
> maintainance purposes, they've tradeoffs:
I don't really disagree with any of this, and especially not with your
suggestion to use HTML preprocessing rather than server-side scripting
if all that's wanted is a templating engine.
On the other hand, it is possible to use server-side scripting and
make the pages *look* static to the end user, which is obviously
worthwhile for those pages that need to be dynamic but aren't
inherently uncacheable.
http://www.mnot.net/cache_docs/ is (still) a good page on the subject.
> 1) HTTP cache control. For example, conditional GET operations will
> always think that documents have been changed and reload them.
> The HTTP cache control mechanism is really subtle. A large part of
> RFC-2616 deals with it. Dynamic pages break that.
With Apache 2.2 and CGI setting a Last-Modified header in the CGI
script is sufficient to get proper 304 responses on If-Modified-Since.
You also get arguably easier control over Cache-Control with
server-side scripting than with .htaccess.
> 2) Typically, the server don't send a compressed stream for dynamic
> resources even if the user agent declares a Accept-Encoding header
> including gzip, compress or other compression algorithms.
> Compression can reduce by 3 or 4 the file size! Both the server and
> client benefit from this!
Again, Apache 2.2 and CGI works fine with Accept-Encoding: gzip at
least. I've not tested the others.
> 3) HTTP 1.1 partial downloading is very unlikely to work with dynamic
> content. This does matter for big files only. Below 400 kilobytes,
> it's not very important.
If a web page is above 400kb it could probably do with splitting
anyway! Something to bear in mind for dynamically-generated images,
though, where a useful compromise is to dynamically generate it the
first time, then save it to local storage and in future generate links
to the stored copy.
> 4) The Content-Length attribute won't be specified, though it can help
> the user agent. e.g. User agents use it to display a progress bar and
> automatically, or with user help, they may choose to stop downloading
> the resource if it's too large or to use an alternative download
> manager.
> Actually, the HEAD method looses of its usefulness if the
> Content-Length attribute disappears.
There's nothing to stop server-side scripts from doing:
page = generateContentsOfPage();
setResponseHeader("Content-Length",length(page));
print(page);
Whether that's a sensible way to do things depends on the language. In
the scripting languages that encourage interleaving of code and HTML
tags (<?php ?>, <% %>, etc) it's probably fighting the paradigm too
much. In an XSLT or other document-tree based language or library then
it's pretty straightforward.
For some scripts it might not be appropriate to do this, of course.
> Other minor detail: The Content-MD5 won't be provided while it could
> be useful on unreliable connections.
I don't see this header even on static files. Maybe I just haven't enabled
it in the Apache config, though.
--
Chris
|
| Similar Threads | Posted | | Problem with upgrading my site | May 7, 2005, 9:28 pm |
| Can well-formed but non-validated XHTML have extra namespaces? | November 20, 2006, 10:54 am |
| Recommendations for good Web site hosting company (for personal Web site) | April 16, 2006, 7:49 pm |
| Need help with my site - search function within my site not working?!? | April 24, 2008, 8:52 pm |
| What is this site using | January 4, 2005, 7:48 pm |
| How to add RSS 2.0 to my web site? | August 22, 2005, 6:01 pm |
| Subscription Web Site | August 28, 2004, 9:36 am |
| Site Migration | January 5, 2005, 5:59 am |
| Site critique | February 3, 2005, 5:00 pm |
| Help with web site management | February 11, 2005, 6:26 am |
|
XML Sitemap