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