I'm contemplating using include to call a cgi script, something like -
<!--#include virtual="/cgi-bin/hello.cgi" -->
to insert some navigation links. I want to render the link to the current section and page as normal text and visibly different.
However, it's likely that actually writing the perl/cgi code will be beyond me and I will have to resort to inserting a boilerplate list of links using something like -
<!--#include virtual="hello.txt" -->
For validation, is it more sensible for the included "source" files to be .txt files?
On the other hand, many of the example SHTML code I've seen use .shtml files as the source.
If the source files are .shtml and the option "entire site" is selected when validating, do the "source" files pass because they are recognised as being exactly that, therefore NOT subject to validation?
it is the fact of naming the "parent" file something.shtml that makes the server look for SSI includes (and other directives) within that and any subsequently included files.
i'm not sure what selecting "entire site" does for your validation tool.
if it spiders from a home page then it should only see urls that are internally referred.
Of course, I'm a burke!
>>because the validator should only see what the browser sees<<
Dear oh dear.
>>if it spiders from a home page then it should only see urls that are internally referred.<<
I'm obviously ignorant of validator behaviour too. I do know that it checks all links in all pages 'cos I fell foul of it recently, human error in the sitemap. The sitemap is the only file not generated by a small database I wrote to automate link maintenance after removing the JavaScript navigation. Good thing computers, it's just a pity that (some) humans have to be involved!
In this thread, validation of html code.
If your included content (in this example, your navigation) is most easily edited as a plain text file, use this option.
All dynamic scripting languages - perl, php, asp, etc. - should only be used if you **need** to extract information from other resources or require dynamic features to output the data. An example might be to search a database to display the last ten most recent members to visit your site. Obviously you would want a program to get this data on demand rather than reading in the info manually and editing text.
Think of perl and other dynamic programs as tools to do work for you as needed, as conditions change. Examples are the reactions you would want to generate from user input, such as submitted forms, searching functions, and shopping carts, etc.
There are also issues you need to address when using perl programs for SSI inclusion that are different than just outputting a perl script to a page. Usually for all the above reasons, you will want to pass a variable input parameter to a script when using it for an include - this is done differently since there's no form to submit. :-)
So the bottom line, for reasons other than you ask, is you're best advised to use a plain text file as the include for your navigation.
Well, I don't understand everything you wrote, but I'm fairly certain I get the jist<s>.
Yesterday, when I was struggling with perl syntax, I created a quick and dirty txt file for include and it was as easy as pie. But I have since sorted a cgi solution for something a little more dynamic.
It's laughable that I should use the word "dynamic" compared to the functionality I've seen, but it's all I need.
