Mmm...
Why? Kevin, for example, uses it to include fragments of JavaScript. Another possible use is including customized CSS. In general, anything that one needs to include in more than one CSP page, and that needs to be easily changed, would qualify for csp:include.
But if it's "static" content it could also be included with <!-- #include -->
(Again, I find the use of the phrase "CSP page" confusing in this context. In my view, a CSP *page* is the whole thing, as served to e.g. the browser, and a mere fragment of that is -- well, a fragment.)
I guess that's for Bill to answer - but in my understanding as a thread's "spectactor", what he means is that anything that generates dynamic content in this context is CSP. It may not be a full blown page. In fact I could argue that "the whole things, as served to e.g. the browser", is not a CSP page but the result of executing one :) Which may be HTML, SQL, XML, CSS, JS, PDF...
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.
Are there any differences I'm not aware of, that refute my statement that the only difference is compile-time/runtime substitution? (BTW, *if* that is the only difference, a simple flag attribute in csp:include could have made <--#include --> redundant.)
I *think*, but I'm not sure, there are slight differences in the actual implementation, but of course that is obvious (mostly having to do with whether the run-time inclusion provides access to the same %request and so on). But yes, I guess using a flag would be better. 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...)
-- ZCacheLib - Open Source Extensions for Cach� http://www.zcachelib.org
