The approach of published objects is a slightly more structured MixedConcerns strategy. With this approach a server maintains a hierarchy of objects or classes (in the OO sense) instead of a file system hierarchy. The URL of an incoming request is then seen as a path along this object hierarchy leading to a particular object.
Objects usually have an inheritance hierarchy, but they could also be said to have a containment hierarchy (via attributes or other method). Either of these hierarchies can be used for mapping a request to an object. (For example: Zope and CherryPy use containment hierarchies.)
Depending on the system, a special method of the object (like render()) can then be called by the request.
The URL can also be taken to denote a method of an object in the hierarchy---so that each request results in a method call (as with published code approaches. Again method signatures can aid in specifying and type-casting request parameters for use in the body of the method.
An object may have attributes other than methods and, although these are generally private and thus not directly addressable via a URL, a method so invoked can access these private attributes (some of which could be templates).
By using such an organised collection of methods and templates (and in fact many different kinds of objects), a programmer has access to many tools that are available for structuring the way in which a request is handled and for constructing a reply.