[Zope-dev] SiteAccess improvements

[Gary Poster]

Hey.  Thanks for your return thoughts.
----- Original Message -----
From: "emf" <mindlace@imeme.net>
> Gary Poster wrote:
> > * I need the ability to store arbitrary properties for each virtual
host.
> > In particular, the correlary of my current work is to provide a
> > CMFVirtualHost tool that stores a sub-portal title, sub-portal skin
> > information, and other items.
> hmm.. I can see why you might want to do this. it's not clear to me that
> this is where it should be done. I'd submit that a "SiteMonster" like
> thing would be more appropriate, as skinnish things, imho, probably want
> to live where an appropriately delegated manager can get at them (the
> target folder, not the root folder/control panel)

Point taken.  The biggest reason to do the CMF tool the way I describe is
that a centralized CMF virtual host tool is easier for the skin tool to
find.  Also, the CMF tool, as a filter to my root Virtual Host properties,
doesn't store any data itself (and presumable a "SiteMonster" would).
Storing all the data, including CMF-specific data, in one place was meant to
encourage data integrity.  The drawback is potential overlap of variable
names.  I thought about doing a simple XML namespace naming convention
solution, but rejected it on the grounds of overkill.  All of this might
still be the wrong decision, but I think it will work as planned and don't
want to go back the drawing table again unless really necessary.

Permissions are a sticky thing, I agree, that would be more easily handled
if the host object were owned by the pertinent folder owner.  I have a vague
idea of somehow making permissions mirror the permissions of the mapped
folder.  Um...this is a bit of a "and then a miracle occurrs" planning
moment.  I'm fairly confident I can come up with a reasonable solution when
I get there.  heh.  heh.

> > * I need the ability to have multiple domains point to the same folder,
> > while ideally maintaining the arbitrary properties
> The current/enhanced VHM has this ability

Not exactly.  The key is "while ideally maintaining the arbitrary
properties".  This is really a matter of efficiency, which becomes
particularly important when multiple properties get involved.  Example:
mysite.com, mysite.net, and mysite.org all direct to the same folder.  They
all have the same title, the same CMF skin options, the same everything.
The current system requires three separate entries, which then would require
manual maintenance of three sets of identical properties.  Unnecessary, and
error-prone.

> > * while I'm at it, some regex capability seemed like a reasonable
addition.
> > I hope to come up with a clean UI way of doing regex substitutions (\1
etc.)
> > as well: anythingNotWww.myhost.com tries to go to
> > /myCMF/members/anythingNotWww, for instance.
> Well ... right now we just have subdomain globbing, so if you had two
rules:
>
> *.myhost.com /myCMF/members/anythingNotWww
> www.myhost.com /myCMF/
>
> you would get the behaviour you describe.  I'm a bit leery of adding
> regexing as if you want complex behaviour, AccessRules already cover you.

I hear you.  It shouldn't be that hard to do, though.  And my example was a
poor one.  Here's a better idea of why I mentioned regex group
substitutions:
CMF member folders: janedoe jackdoe joedoe jessiedoe
Advertise to members: "Have your own website at [your name].mysite.com!"
Be able to generically map any server other than "www" to the member CMF
folder so that
^([^,]*)\.mysite\.com can map to (sorry, using Perl $1 for first match for
simplicity) a root of /myCMF/Members/$1
Thus janedoe.mysite.com has a root of /myCMF/Members/janedoe.  Same for the
other member ids.  idontexist.mysite.com would give an ugly error.  Members
that become clients can have their own mapping, so that they can have a
personal skin

> > * also while I'm at it, it seems that making the management of the
virtual
> > hosts a little more zope-like would be nice.  Here's where my
inexperience
> > may be become particularly obvious, but... I'm making this a
> > VirtualHostFolder, similar to a acl_users folder except ordered (so you
can
> > tweak the order that the hosts are checked for a match).   The
VirtualHost
> > objects it contains are not to be actual products but objects the way
that
> > Users.py defines users.  The VirtualHostFolder is not an actual
> > ObjectManager but just emulates one a bit a la an acl_users folder.
> Makes sense, especially if you want to extend their behavior as you
> mention above... I'm more of the assumtion that target folders will know
> their special behaviour, but I'm open on that one.

Again, data integrity and ease of connecting to other CMF tools were my
deciding factors (not to mention that CMF likes tools, skins and content
types as its main customization hooks).  And again, it's just what I thought
would work--permissions are a question.

Thanks again for your thoughts.  Now I better get cracking on it some more
and close down Wizardry 8...tomorrow. ;-)

Gary