Advocacy
Dojo (HowTo)
Reference
Markets
Museum
News
Other
Myths
Press
General
Hack
Hardware
Interface
Software
Standards
People
Forensics
Web
CodeNames
Easter Eggs
History
Innovation
Sightings
Opinion
Martial Arts
ITIL
Thought
|
Of all the "technologies of the week", the one that most WebMasters (who are doing a site more than a few pages) should really look into is Server Side Includes (SSI).
What are they?
Server Side Includes are a server technology. The WebServer looks at each page as it is streaming it out, and looks for a special tag <!--#include virtual="path/file" -->. As the server is transmitting the file, it replaces that special tag with contents of the file that command directs it to. The file becomes "included" in the stream, by the server -- hence the name, a server side include.
If you aren't sure what I mean, think of this --
File.html
This it a test of the emergency broadcasting system...
<!--#include virtual="path/IncludeFile" -->
If this had been an actual emergency, the annoying tone you just heard, would have been preceded by the sudden deaths of you and your loved ones...IncludeFile
This is ONLY a test...
Output (what the browser would see) using Server Side Includes
This it a test of the emergency broadcasting system...
This is ONLY a test...
If this had been an actual emergency, the annoying tone you just heard, would have been preceded by the sudden deaths of you and your loved ones...
Well SSI may not sound like a big deal -- but it certainly can be. The technology is simple and elegant and can allow you to do all sorts of things.
Frames
It can give you all the versatility of frames, without the ugliness. I would strongly urge anyone using frames to use SSI instead.
Frames allow you to break common elements into separate files, and include all those files on one compound web-page. SSI does the exact same thing. Instead of having three frames, that each include a sub-file, you have three included files, laid out in a table. About the biggest difference is that you can't scroll the frames separately, and they really do become one page. For MacKiDo, I just include a "ControlBar" (that area to the left of the screen that has the Controls to take you to any topic). If I want to replace (fix) one of the common elements, then I just fix the included file -- and every page will include that fix instantly.
Breaking common elements into separate files (for maintenance purposes), is the most common reason webmasters use frames. So with SSI you get the same result as frames (from a webmaster point of view) -- except that it can be viewed with any browser (not just a frame compatible one). Not only that, but people can actually bookmark your pages directly (something that is a pain with Frames), and you don't waste all this effort with the "target". (If you don't know what that is, then you don't use frames correctly -- if you are using it, then you know that it can be annoying). So SSI is a better way to do frames than frames are.
Separating the Body from Format
My article on metatags discusses some of the advantages of separating the style (format) from the body (text). This is what CSS (Cascading Style Sheets) are going to try to give us, over the next few years. But while CSS technology, will only working with a minority of browsers (and add complexity), using the metatag method can be used immediately and works with all browsers (obviously depending on what tags you choose to use).
Reread the metatag article, and think about what SSI can do for you. Did you get it? You can just do all the things that you were going to do using metatags -- but you do them dynamically (without the "compile" or search and replace phase). The server side includes will replace all of your formatting information on the fly.
Create a template like this --
- <!--#include virtual="path/ControlBar.part" -->
- <!--#include virtual="path/TitleFormat.part" -->
- Article Title Text
- <!--#include virtual="path/AuthorFormat.part" -->
- Author Text
- <!--#include virtual="path/BodyFormat.part" -->
- Body of article
- <!--#include virtual="path/EndingFormat.part" -->
Now, you can just create the TitleFormat file once, all files that use your article template, will be using your format. The same with the author, and the body, and for closing any formatting (tables) that you might have at the end (or adding a standard ending block, and so on.
This is exactly how this version of MacKiDo is being generated.
So if I want to add a topic in my ControlBar, I just add it once -- upload that one included file, and the entire site is updated instantly.
I created a standard table for the top, that has pathname, Article name (title), brief description, and who the article is by. Each of those is an "include" file. The formatting gets pulled in from those parts on the fly -- and if I want to change the color of the top block, it is just a tweak of one file. (I also have a little ending block, that also gets its parts pulled from include files).
This helps with the consistency of the site, because everything uses the same formatting, and it helps with the ease of updating. And it makes a very simple template file. So I can give writers an empty article (with the metatags -- that just happen to also be "include" tags), and they fill in the blanks. I put it up on my site, and I have a fully formatted article -- without the search and replace or "compiling".
So Server Side Includes are better use of metatags than plain metatags!
Configuration Management
A good idea is to reread the Configuration Management article as well. Basically, it describes a traditional data-collision problem -- where two people want to edit the same file, at the same time. The problem is basically this -- I download the MacKiDo Home page (to update a new "lead" article), and Fred Downloads the home page (to update a new AppleBits section), and whichever one of us uploads last, stomps the other.
Well, guess what. Server Side Includes can fix this problem as well. If the home page is just a file that says:
- <!--#include virtual="path/LeadArticle.part" -->
- <!--#include virtual="path/AppleBits.part" -->
Then Fred can update the AppleBits fragment, and I can update the leader fragment, and we can never collide. Most configuration management problems are immediately solved.
NOTE: This only works well if there are different people working on different sections. If we both wanted to work on AppleBits, then we would still have the problem, since we would both try to edit the same included file. Fortunately, we don't work that way -- and it is best if people have their own areas of responsibility anyway.
In fact, the home page can be built from many parts, making it easier to prevent data-collision.
Conclusion
XML -- On of the biggest advantages of the XML standard that was just passed (and SGML before it), is that they can both handle "included" files -- or compound files built from parts. It can also do more -- but this is a key part of XML. The XML Syntax (for doing includes) is slightly different than SSI's included files -- but it should be very easy to replace one with the other. So if you use Server Side Includes today, you are taking the first step towards using XML tomorrow. (Realistically, with XML just getting adopted, it could be quite some time before the tools to utilize it will be "common", but it doesn't hurt to think ahead -- especially on the web)
So I hope you can see how versatile Server Side Includes can be. The concept is very simple -- but the applications are very diverse. I would have used them far sooner (I knew of them, and what they could do), but I didn't know that my "host" provider would allow me to use them. Once I found out that they supported them, the choice was clear -- and the MacKiDo was made to use them. Already it has made my life (as a webmaster) much easier.
Server Side Includes Resources
- http://zippy.sonoma.edu/~kendrick/nbs/unix/www/ssi/
- http://www.carleton.ca/~dmcfet/html/ssi2.html
- http://search.yahoo.com/bin/search?p=Server+Side+Include
|
