Toby Dickenson wrote:
Is it *really* the case that you often want to method to be called directly via the Web *and* and from DTML? This doesn't seem right to me.
Im suprised that you are suprised. Consider a method called 'summary' that returns a plain-text summary of an object. Thats useful to call from DTML (maybe assembling a summary of several objects), via xmlrpc, and directly from ZPublisher (by browsing to the url of the method).
I'd like to refer you to a discussion we're having. http://dev.zope.org/Wikis/DevSite/Projects/CacheManager/Architecture The issue is that since a called object has no idea who called it (nor should it know IMHO), it has no idea whether it is appropriate to set response headers that apply to HTTP caches. Headers should be set only if the object was invoked by ZPublisher. In most cases this is not an issue since cache setup is performed by a human who knows which objects are supposed to be published and which are not. However, I think the possibility for side effects (where a piece of a page inappropriately generates response headers) is great enough to warrant a separate API call. This can happen when an object is set up with a cache manager but later repurposed. Consider that in the current version of PythonMethod, the document_src() method sets the Content-Type header whether it was invoked through ZPublisher or not. When DTML invokes document_src(), this has the effect of causing all HTML on the resulting page to be rendered as "text/plain". Note that cache headers can be harder to debug than content-type headers, and that this mistake was made by one of the brightest hackers I know. :-) Shane