Hi. My main project right now is actually to build a VHM replacement for myself to solve some needs I had. I was basing it off of imeme's enhancements of the original VHM, and will release it quietly when I have a beta. This might very well be a new entry in my list of vaporware. However, I thought you might at least be interested in my goals for the VHM, to see if you thought they were of interest to you in your planning: * 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. * I need the ability to have multiple domains point to the same folder, while ideally maintaining the arbitrary properties * 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. * 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. We'll see if I'm barking up the wrong tree as I try to build it this weekend. Anyway, this project has to get done very soon for me--either to complete a beta or decide it can't be done. I very much like your idea to put it in the control panel but I have no idea how to do that, and it's not a current need of mine. I was just going to make the management constructors regurgitate some exceptions if it wasn't placed in the root folder or if another one was already there. The control panel placement would be nice though, as far as I'm concerned, as long as my arbitrary properties could still be accessed. Well, there's some thoughts. Like I implied, it's probably best to ignore my vaporware announcement; if I come up with anything not embarrassing I'll post it somewhere or other soon. imeme is cool btw. Gary
Date: Sat, 24 Nov 2001 01:13:01 -0700 From: emf <mindlace@imeme.net> To: zope-dev@zope.org, evan@zope.com Subject: [Zope-dev] SiteAccess improvements
Hello,
There's a very nearly "orphaned proposal":
http://dev.zope.org/Wikis/DevSite/Proposals/SiteAccessUsuabilityImprovements
iMeme has already done some work towards these goals with "SiteAccessEnhanced": http://www.zope.org/Members/sfm/SiteAccessEnhanced
I am taking over this effort, and I have some near-term "goals outlined": http://dev.zope.org/Wikis/DevSite/Proposals/SiteAccessProposedSolutions
I intend to deliver the VHM improvements before the AccessRule
improvements.
Please give feedback on this proposal, and let me know what I need to do to move this into the project phase.
Thanks, -- ethan mindlace fremen | iMeme - The most full featured Zope Host http://mindlace.net | Root, ZEO, MySQL, Mailman, Unlimited Domains iMeme Partner | http://iMeme.net "It is our desire to remain what we are that limits us. -- Project 2501"
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)
* 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
* 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.
* 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.
Well, there's some thoughts. Like I implied, it's probably best to ignore my vaporware announcement; if I come up with anything not embarrassing I'll post it somewhere or other soon.
Thanks- let me know what you come up with.
imeme is cool btw.
Thanks! -- ethan mindlace fremen | iMeme - The most full featured Zope Host http://mindlace.net | Root, ZEO, MySQL, Mailman, Unlimited Domains iMeme Partner | http://iMeme.net "It is our desire to remain what we are that limits us. -- Project 2501"
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
Gary Poster writes:
Hi. My main project right now is actually to build a VHM replacement for myself to solve some needs I had..... ..... * 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.
* I need the ability to have multiple domains point to the same folder, while ideally maintaining the arbitrary properties I expect these two requirements are already possible without any modification to VRM.
Assume, your destination folder is "I" (for implementation) and you have configuation objects "C1", "C2", ... one for each of your virtual domains "D1", "D2", ... The configuration objects could be any object capable of holding the configuration information and inheriting from "Acquisition.Implicit" Then you rewrite your virtual domain URL for "Di" into VirtualHostBase/Di/Ci/I/VirtualHostRoot Due to the magic of acquisition, your should get the configuration into your implementing "I". Dieter
Thanks Dieter! You're quite right, that sounds like it would work--and it is something I wouldn't have thought of, so good to have a reminder of acquisition magic in somewhat different contexts I've got a beta of the non-UI features of my replacement already, and since I've invested some work in it and I think it would be a more graceful solution in the end anyway (YMMV) I'm going to go ahead with it. Still, really much appreciated. Planning to release my clunky early beta within the week; I'd love to hear your suggestions on it when it comes out. Thanks again. Gary ----- Original Message ----- From: "Dieter Maurer" <dieter@handshake.de>
Gary Poster writes:
Hi. My main project right now is actually to build a VHM replacement for myself to solve some needs I had..... ..... * 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.
* I need the ability to have multiple domains point to the same folder, while ideally maintaining the arbitrary properties I expect these two requirements are already possible without any modification to VRM.
Assume, your destination folder is "I" (for implementation) and you have configuation objects "C1", "C2", ... one for each of your virtual domains "D1", "D2", ...
The configuration objects could be any object capable of holding the configuration information and inheriting from "Acquisition.Implicit"
Then you rewrite your virtual domain URL for "Di" into
VirtualHostBase/Di/Ci/I/VirtualHostRoot
Due to the magic of acquisition, your should get the configuration into your implementing "I".
Dieter
participants (3)
-
Dieter Maurer -
emf -
Gary Poster