[Zope-Annce] VirtualHostFolder and CMFVirtualHost

[Gary Poster]

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)