Shortly after I published the Lowdown on
article, I received two great comments from two 4Guys faithfuls. I thought I would share their comments.
I read your shpeel about includes. I regularily take a few hours each week to peruse your articles and consitently learn from slick to down right ingenius techniques. I actually have something to offer for once.
We also discovered the security hole of include files. A client got the error
...include file xxx.inc
not found - and managed to type it in and view db passwords (shit!) (missed an update to multiple
web servers...) We now set up IIS to script
.inc files as
.asp files. Just
add as you did the
.scott files (which is such a cool idea -
just has such a nice ring to it). As you mentioned, include files are brought in first, then the whole
piece is scripted, so this does not affect performance, just security. All of this is negated by naming
include files with
Lastly, include files are awesome for header/footer/navigation code, particularily when you have dynamic logos and urls. Write one db function for images, nav, header... include in the top of every page... done.
Thanks for all the great advice and information. Keep up the good work.
From Stephane P.
Many thanks for you great article about include files. I'm an evangelist for the usage of include files for quite some time, and your article is AFAIK the first one, which supports my point of view of 'good ASP programming partice' in this particuliar issue :-)
I've found, that the two Scott's Programming Axioms are more than correct, e.g. I've created a number of functions and procedures, which produce correct HTML output by just passing some variables to them, e.g. recordsets, requets objects, etc.. This allows me to write error-free, cross-browser HTML-output on all my pages. Of course, I could use a WYSIWYG editor, but we all now the problems related to them :-), or I could achieve the same with an ActiveX.DLL, but the developmet cycle is much faster by using include files.
Although include files are a great way to minimize the errors and maximize the productivity with reusable code, some conceptual things have to be considered before using them, to maximize its revenue. I have collected 5 additional tips of using include files, you might want to include them in a follow up article :-)
1) Split include file logically, i.e. have several include files for specific tasks and names them accordingly. E.g. I have an include file 'times.inc', which does all sort of thing with times and dates, like country specific display, extended dateFormat-functionality etc. This helps to better organize the include files and minimize the time to search for the syntax a particuliar function.
2) Separate constants and global variable declarations from functions and procedures and don't mix them in the same include files. Globally declared variables and constants change more often than functions and procedures, therefore only one file needs regular update, and an update of the declaration file has no effect on other applications, which use include files as well.
3) When Programming for customers, it is a good idea to have environment specific information, such as file system information, ODBC DSN,'s, logins etc., in a dedicated include file, e.g. 'environment.inc'. This allows to develop your application in the virtually same environment as the customers place, you don't have to bother for system dependencies, the 'environment.inc' takes care for the localities.
4) Place your include files in a dedicated directory, as you suggested. This helps to organize the environment and minimize the problems with duplicated (and different!) include files. Place a include file in each application directory, which includes the necessary include files from the include directory.
5) Last, but not least, make use of ASP in include files. As include files are included by the
SSINC.DLL, but processed by the
ASP.DLL, any valid ASP script code in include
files is processed as if written in the ASP page itself. This is another easy way to generate 'dynamic'
includes. The only other way is to use the FSO, as you suggested.
We are managing and maintaining an Intranet at one of our customers place. about 10,000 people are viewing, editing, creating and maintaining Intranet-homepages, and we have set up everything with include files, e.g. templates and design elements, navigation bars, etc.
I'm a regular visitor of your site, and very much appreciate your endeavour to support the ASP community. As a former Microsoft MVP on IIS and ASP, I know, that ASP programmer, especially beginners, are often irritated by the reference documents around. Your website offers well written and easy to understand examples and explanations, and is a rich source, even for experienced programmers like me :-)
Keep up the good work.
Thanks, Stephan and Rusty, for your great comments! If you'd like to add your two cents, be sure to send me feedback!