http://www.zope.org/Members/poster/VHF/index_html VirtualHostFolder (VHF) beta 0.3.0, a replacement for SiteAccess' VirtualHostMonster. For the end-user, a powerful and very configurable virtual host solution, including regular expression matches, per-host redirects, per-host folder aliases, and powerful CMF skin functionality (see below). For the developer, a component-based system for you to add your own host functionality, and a reasonably thorough API. http://www.zope.org/Members/poster/CMFVirtualHostTool The CMF Virtual Host Tool provides CMF access to the VHF, and allows you to host sub-portals within the CMF, with their own skin lists and default skin, their own title, flexible breadcrumb functionality, and more. Some other folks are planning on joining in on development, so I've also started using SourceForge cvs (https://sourceforge.net/projects/vhf/). It looks kind of like a ghost town there now, but if you go into cvs you'll see we've had a couple of check-ins. The releases listed above are current with CVS as of this instant, however. ---- And now, once more, for those of you who want to know more...

What are the main differences of the VHF and the host monster?

Well, I guess I'd say the biggest difference is that it is a component system, instead of the monolithic VHM. The VirtualHostFolder is, as the name suggests, a folder for various host objects: each host object is intended to represent one logical virtual host. That basically means you will create one host object per virtual root. During the traversal, the VHF then asks each host if it wants to handle the request (the VHF is an OrderedFolder so you can control the order of when hosts are checked) and the host either claims it, and then processes it, or not. The whole system uses interfaces so that you can substitute in your own host object with your own special features as long as it declares and implements the required interface. It comes with a fairly powerful implementation of the Host interface that lets you match domain names both with strict string matches and regular expressions. The supplied Host implementation also can contain components that implement an IHostOverride interface (see Contents tab). These objects can alter the Host behavior for certain paths. The two HostOverride implementations that currently come with the VHF are a Redirect class (that can, for the current host only, redirect any path that matches a regular expression to a location you select) and an Alias class (that, for the current host, can insert itself in a path dynamically to be in effect a TransparentFolder to any other location in your Zope tree). The supplied Host implementation also supports a CMF-centric interface--more below. I have also defined elements of the IVirtualHostFolder and IHost interfaces so that developers can have a central API for querying what virtual host behavior is going on for the current request. You can see these features by looking at the interfaces. It is fairly comprehensive, I think, but I may have left some things out. There are a number of other noteworthy features as well, such as the testing tab in the main VHF that lets you type in a domain name and see the stack and some of the other results that the VHF would spit back as it is currently configured for that URL. Explore and I'm sure you will find other elements I've missed. To close, I should mention the CMFVirtualHost. The biggest job it does is let you limit the CMF skin list for a given host, so that only certain skins are available for each host, and so that you can define a different default skin for each host. It does this by allowing the CMF portal manager to limit skins, and then allowing the owner of the folder that is the root of the current virtual host to further limit skins from what the uber-manager set, and set the default skin for the current host. It changes the preferences page (both dtml and zpt skins) so that these choices are manageable there. It also lets you access much of the VHF API discussed above. It also uses the virtual host title, rather than the portal title, as the main site title in the default skins. It also provides a breadcrumbs method that is fairly powerful and that can handle the various path tricks that the VHF components pull (particularly the alias). Probably some other things that I'm forgetting. There are some other features I'm thinking about and have made some progress with like setting and getting arbitrary properties per host from CMF with definable security settings, but I'm not sure how that would be most useful yet. TO DO: The UI is um, not friendly. Improve. Unit and functional tests: I haven't built any yet, and I am starting to really wish I had. A couple of small "to do" holes, marked in the code More and better help files Instructions for setting up with Squid, maybe. Other servers? From what I've heard, NT IIS server won't let you rewrite the request the way the VHM/VHF need so that may be out... Alias/ZPT/CMF issue (waiting to hear back from ZC on this one)