Ram�n Jim�nez wrote: >But if it's "static" content it could also be included with <!-- >#include -->
Imagine "static" content, included in hundreds of pages, that needs to be changed... You'd have to recompile all those pages at every site, as opposed to simply distribute the new content. The only reason to do a compile-time include that I can think of is the slight gain in performance. Note that I don't object to #include; I just imagine that in most cases csp:include is more useful. [What exactly is a "CSP page"] >Not that I'm saying you're wrong or anything... Just trying to make >sense of it all. It would be a petty issue to argue over IMHO. It's not that important, but what I described is, at least, how *I* interpret the phrase, and I always found the docs referring to "including another page" confusing. It wouldn't hurt to make them more clear on the subject. But the important point is not in the term used, it is in the implied difference with what's included with #include. I still fail to see that difference. Did I already mention that files included with #include can have dynamic content as well? (I know I did, just wanted to stress it again. ;)) I wrote: >> Are there any differences I'm not aware of, that refute my statement >> that the only difference is compile-time/runtime substitution? Bill mentioned that the csp:include is run through the (internal?) web server. This would probably create a different environment for the included file. I don't know what the exact consequences would be, though. >Even cooler: have >Cach� determine the type of the included file at compile time and >compile in/runtime include the file as needed? (Something akin to MIME >type auto-detection...) Not for me, thanks ;) I'd rather decide for myself, and besides, the compiler can't detect changes to the included file's content that would influence it's decision on whether to include at compile-time or at runtime. (Unless you recompile the including page, of course, but that would defeat the purpose.) Gertjan. -- Gertjan Klein
