but it has some shortcomings I'd like to avoid... seems like (haven't tried yet) Server.Execute code runs in another context, so you can't use it to load a functions your are planning to use in the caller code... nasty...

You CAN do dynamic includes. Have a look at the technique below...
–
atwrok8Jun 17 '09 at 19:40

@atwrok8: I don't think you have correctly understood the distinction between an execute and an include.
–
AnthonyWJonesJun 17 '09 at 21:19

1

I understand the distinction between Server.Execute and the #include directive perfectly. Just because the term "dynamic include" is used, doesn't mean it has anything to do with the #include directive. In regard to classic asp, the term "dynamic include" is almost always used to describe the problem of using a piece of code dynamically, based on some runtime logic. The links supplied by opensas all point to various solutions to this problem, and I'm almost certain opensas isn't asking specifically about the #include directive.
–
atwrok8Jun 17 '09 at 22:03

Sure you can do REAL classic asp dynamic includes. I wrote this a while back and it has opened up Classic ASP for me in a whole new way. It will do exactly what you are after, even though people seem to think it isn't possible!

@atwork: This doesn't do an include and for the record just re-iterates what I've already stated in my answer the closest you can get it a Server.Execute. There is an important difference between an Execute and an Include. An execute uses a fresh new script context all the code and variables are enclosed in that context for the page executed. An include inserts code into the current script (before any code runs its a static thing) and then the whole code executes in the same context, sharing variables and functions.
–
AnthonyWJonesJun 17 '09 at 21:18

I'm a bit rusty on classic ASP, but I'm pretty sure you can use the Server.Execute method to read in another asp page, and then carry on executing the calling page. 15Seconds had some basic stuff about it - it takes me back ...

I am building a web site where it would have been convenient to be able to use dynamic includes. The site is all ajax (no page reloads at all) and while the pure-data JSON-returning calls didn't need it, all the different html content for each different application sub-part (window/pane/area/form etc) seems best to me to be in different files.

My initial idea was to have the ajax call be back to the "central hub" main file (that kicks the application off in the first place), which would then know which sub-file to include. Simply including all the files was not workable after I realized that each call for some possibly tiny piece would have to parse all the ASP code for the entire site! And using the Execute method was not good, both in terms of speed and maintenance.

I solved the problem by making the supposed "child" pages the main pages, and including the "central hub" file in each one. Basically, it's a javascript round-trip include.

This is less costly than it seems since the whole idea of a web page is that the server responds to client requests for "the next page" all the time. The content that is being requested is defined in scope by the page being called.

The only drawback to this is that the "web pieces" of the application have to live partly split apart: most of their content in a real named .asp file, but enough of their structure and relationship defined in the main .asp file (so that, for example, a menu item in one web piece knows the name to use to call or load another web piece and how that loading should be done). In a way, though, this is still an advantage over a traditional site where each page has to know how to load every other page. Now, I can do stuff like "load this part (whether it's a whole page or otherwise) the way it wants to be loaded".

I also set it up so each part can have its own javascript and css (if only that part needs those things). Then, those files are included dynamically through javascript only the first time that part is loaded. Then if the part is loaded repeatedly it won't incur an extra overhead.

Just as an additional note. I was getting weird ASCII characters at the top of the pages that were using dynamic includes so I found that using an ADODB.Stream object to read the include file eliminated this issue.

So my updated code for the getMappedFileAsString function is as follows