As HTML has turned out to be incredibly useless very soon, many people have written several extension trying to reduce this uselessness. Most of them only increased it. However, this will shortly comment on some of these extensions, and how you can use them together with hsc.
When you process a page with hsc, there is no way to change any data of the HTML object after it has been created; hsc only does a static job. Many of the extensions described below allow documents or parts of them to be created dynamically. But then you will have to care about several security problems.
Most of these concepts integrate themselves into HTML in a fairly
clean way (usually by means of sgml-comments). For others you will
need to utilise
<| .. |> (skip verbatim data) to make hsc accept them. If this
still does not help, there is no way to use a specific extension
together with hsc. There definitely will not be built-in support for
any of these extensions.
This chapter does not pretend to describe all of them, but most suggestions provided here should also work with most others extensions. You also will not find any information about where to obtain these tools from. Ask your favourite w3-search engine for details.
Server Side Includes (SSI) are one of the oldest extensions for w3-servers. An example command would be
<!--#echo="DATE_GMT"-->which more or less does the same as
in hsc, with the difference that the ssi-version will be executed every time one accesses the page.
As the SSI-call is done inside a sgml-comment, hsc will not care about it and simply skip it. Only make sure you did not set the command line option StripComment. The sgml-comment will be substituted by your server later (if it supports SSI).
Usually SSI-operations result in an increased CPU-load of your server, as they have to be performed every time one accesses the page.
Most w3-servers also support the so called Common Gateway Interface
(CGI). This is just the simple capability to return the output a
program wrote to
stdout as w3-page. CGI-programs are usually
unreadable and unmaintainable Perl-scripts more or less entirely
consisting of statements like
Ill-minded people could think about invoking hsc inside a CGI-script. I do not recommend this for several reasons that should be obvious.
The Personal Home Page Tool/Form Interpreter (PHP/FI) started as a messy Perl-script acting as some simple CGI-wrapper. As time passed, it grew to a inflated and inconsistent moloch providing a simple programming language inside HTML-documents. It also supports things like embedded SQL, and some people with other presuicidal syndromes even use it as a plug-in with their w3-server.
The syntax does a very good job on combining the drawbacks of C with the disadvantages of Perl, in general resulting in a completely unreadable sequence of seemingly random characters. Therefore, it became quite popular among Unix-fossils. For example, one could have this line in a source code:
<?echo "Hi $Name!<p>">If you pass this to hsc, it will not be very happy about it. However, you can use
<| .. |>(skip verbatim data) to include PHP/FI-stuff:
<|<?echo "Hi $Name!<p>">|>If you want to access data of hsc into your PHP/FI-section, it will become a bit tricky. But with
<( .. )>(insert expression) even this is possible:
<$define Name:string="Sepp"> <( '<|' + '<?echo "Hello, ' + Name + '!">' + '|>' )>will temporarily result in
<|<?echo "Hello, Sepp!">|>and after being processed by hsc a
<?echo "Hello, Sepp!">
will show up in the HTML object. If you are really sure that code like the above will not significantly reduce your life expectancy, do not hesitate to use it. But if you use PHP/FI, you apparently are sure about that.