I've put together a proposal for hosting vertual domains in Zope. See: http://www.zope.org/Members/jim/SiteObjectProposal Comments? Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
This is exactly what I've been working on; I call them 'SiteRoot' objects :-) Nowhere near done, and I'd love to collaborate. ----- Original Message ----- From: Jim Fulton <jim@digicool.com>
http://www.zope.org/Members/jim/SiteObjectProposal
Comments?
I really like your ideas about absolute_url() and making the re-rooting a method of Request objects. What do you mean by 'Integrated Session Management'? Here's how I've approached it so far: o All functionality lives in the SiteAccess Product -- No patches to Zope source o You may place a SiteRoot object in any folderish object. -- Hijacks __bobo_traverse__ on the container ---- Munges Request values (PARENTS, SERVER_URL, SCRIPT_NAME) with SiteURL property. -- No need to change/replace a hierarchy container -- Container doesn't have to be a vanilla Folder object o PCGI and HTTP Requests will need to be affected in slightly different ways. -- PCGI may already be rewritten and/or vhosted ---- but you might want to manipulate further -- HTTP will always be raw, and require rewriting and vhosting o I haven't the faintest idea what should happen with FTP and monitor access. Probably nothing. o Zope rewrite/vhost rules are handled independently, by AccessRule objects -- You might want to rewrite URLs without multi-siting ---- AccessRules can do cool things like add default context to requests without showing long URLs to the client -- AccessRules can be complex, and may not correlate closely with SiteRoot.SiteURLs -- Manipulating AccessRules is a security risk on the level of adding Products ---- How could customers be allowed to rewrite URLs leading to their own content and nobody else's? -- All AccessRules should be available to SiteAccess when it loads, without poking around in storage -- Thus: AccessRule objects should probably live in the Product, if that can be managed o Acquisition should pass upward through a SiteRoot, but not down through another -- Common content/methods will often be shared among sites -- Only one SiteRoot is allowed in a namespace
This is exactly what I've been working on; I call them 'SiteRoot' objects :-) Nowhere near done, and I'd love to collaborate.
jim, evan, this is exactly what i've been working on too! :-) i call them VirtualHostFolders... the thing i have works, it is a product and a couple of patches to Zope, but it has some issues. i'll post the code this evening, after i clean it up a bit, it might be useful to you. the SiteObject proposal is great, my comments follow....
http://www.zope.org/Members/jim/SiteObjectProposal
Comments?
i've approached this a bit different from either jim's or evan's ways. o Most functionality lives in the VirtualHostFolder Product -- minimal patches to Zope source o VirtualHostFolders derive from the Folder Object -- with an additional property, IPaddress (this will eventually be a list of IPaddresses?) o Small patch to ZServer.HTTPRequest -- so it places the actual socket IP and Port numbers into the request's environment (HTTP_SOCKET_IP and HTTP_SOCKET_PORT) -- i didn't use HTTP_HOST for mapping since it is symbolic; i wanted to have a 1:1 mapping from IP address to path o Small patch to ZPublisher -- allows registration of multiple remapper methods. takes as arguments the object path and the REQUEST, returns a new (remapped) path. -- doesn't solve the generalized remapping problem, but allows a plug-in solution without further patches. -- i map an IP number to a Zope object path, by adding a path prefix to the URI in ZPublisher. this would allow a similar approach to be used for other protocols, like FTP. o new persistent Remapper object -- holds dictionary of IP:path_prefix mappings -- Issue: how and where to store this, since it needs to be notifies upon creation or deletion or changes to VirtualHostFolders, o allows other Remapper objects to be registered -- to do other kinds of object path remapping this approach seems to solve several problems, while creating others. :-) there are no changes access control and permissions. acquisition happens normally. (i think.) one problem or issue i've been grappling with is: where to you store the dictionary of IPaddresses and path_prefixes? it needs to be persistent, and should probably be a Zope object so it can have transaction and version support and other good stuff. but the VirtualHostFolder instances need to talk with it when they are created, changed, or deleted. right now my VirtualHostFolder product does a terrible kludge :-) and stores the Remapper object it its own ZODB in its own FileStorage object in the var/ directory. ugh! i did that because i haven't figured out how to store or open a Zope object in the currently open database from the product's __init__.py file... if this is possible, it seems like the right thing to do would be to make the Remapper object a sub-object of the VirtualHostFolder product, which would then get acquired (?) by VirtualHostFolder instances...? i'm not sure here. why i did it this way: if you take the SiteObject or SiteRoot ways, you still need a centralized dictionary or IPaddress:path mappings... at least it seems this way to me. for performance reasons you don't want to go looking all over the ZODB hierarchy for every request. :-) so if you need a centralized place for the dictionary, you might as well go the route of just using special folder-like objects that can be put anywhere in the ZODB hierarchy... it seems the most Zope-like, and it seems to require the least changes to Zope and to how people understand Zope. i thought about making a product that you could just drop into a folder to make it a Virtual Host, but then... you get the issues of needing to make these invisible to non-managers, you still need a centralized dictionary, etc. anyway, i'll clean my code up and post it this evening (with patches too) for people to look at and comment on. whatever way is eventually chosen, i think virtual hosting is a Good Thing and will help make Zope better and better... :-) cheers adam -- Adam Feuer adamf@pobox.com
I wonder how many other great minds have been thinking alike, here. No doubt we'll be hearing from them soon <wink>. ----- Original Message ----- From: Adam Feuer <adamf@pobox.com>
the thing i have works, it is a product and a couple of patches to Zope, but it has some issues. i'll post the code this evening, after i clean it up a bit, it might be useful to you.
Excellent.
o VirtualHostFolders derive from the Folder Object -- with an additional property, IPaddress (this will eventually be a list of IPaddresses?)
Looks like different needs have spawned different approaches, here. I didn't even think about IP/port issues, since I operate all of my sites from a single address/port through Apache. Obviously both cases will need to be handled.
o Small patch to ZPublisher -- allows registration of multiple remapper methods. takes as arguments the object path and the REQUEST, returns a new (remapped) path.
See my other post, where I lay out something roughly like this, except that the method doesn't return the new path, it passes it to a (new) method of REQUEST.
one problem or issue i've been grappling with is: where to you store the dictionary of IPaddresses and path_prefixes?
I have hit the same wall, and I'm climbing it now. This looks like a standard problem/pattern for Zope Products; How do you keep 'global' information available to instances of classes defined in the Product, preferably in a standard object in the standard storage. I surmise that this isn't a problem for ZClass-based Products <sigh>.
why i did it this way: if you take the SiteObject or SiteRoot ways, you still need a centralized dictionary or IPaddress:path mappings... at least it seems this way to me. for performance reasons you don't want to go looking all over the ZODB hierarchy for every request. :-)
I quite agree. On the other hand, I think it's a Good Thing to separate the act of path extension ('www.site.com/thing' => '/here/is/the/site/thing') from that of logical URL definition ("Everything inside me starts with 'www.site.com/'"). That way, you can define logical URLs once and for all at the location of the site root, while handling direct-to-ZServer requests differently from pre-rewritten through-Apache ones.
i thought about making a product that you could just drop into a folder to make it a Virtual Host, but then... you get the issues of needing to make these invisible to non-managers, you still need a centralized dictionary, etc.
Only the path-extension/rewriting part needs a central dictionary. Does it really need to be invisible to non-managers, or is it enough that they can't mess with it? Only users with "Add new <whatever>" permissions on a folder should be allowed to view/change/delete the <whatever> object.
Looks like different needs have spawned different approaches, here. I didn't even think about IP/port issues, since I operate all of my sites from a single address/port through Apache. Obviously both cases will need to be handled.
evan, i don't use apache and zope together (but i should, i guess? :-) how do you want it to work? from your comments, you obviously don't want to do all your URI remapping in apache. how does apache let zope know what host has been contacted, if the sites use different IP numbers...? if HTTP 1.1 is used, the HTTP_HOST variable will be set, so that isn't a problem. i'll add the code to look at the HTTP_HOST variable first, and check for a symbolic mapping before using the IP address...
See my other post, where I lay out something roughly like this, except that the method doesn't return the new path, it passes it to a (new) method of REQUEST.
is one way better than the other...? i just returned the new path because it seemed like i could tread lightly on the Zope code... :-) but perhaps not...
I have hit the same wall, and I'm climbing it now. This looks like a standard problem/pattern for Zope Products; How do you keep 'global' information available to instances of classes defined in the Product, preferably in a standard object in the standard storage. I surmise that this isn't a problem for ZClass-based Products <sigh>.
yes, i started with a ZClass for that reason, but then it seemed more straightforward to just make the product in python... the ZClass acquisition link is very appealing, though.
I quite agree. On the other hand, I think it's a Good Thing to separate the act of path extension ('www.site.com/thing' => '/here/is/the/site/thing') from that of logical URL definition ("Everything inside me starts with 'www.site.com/'"). That way, you can define logical URLs once and for all at the location of the site root, while handling direct-to-ZServer requests differently from pre-rewritten through-Apache ones.
mmmmm... i am not sure i understand this! :-) or perhaps this doesn't apply to my approach. in my scheme, every request goes thru the Remapper, and the (relative) path gets rewritten (to be an absolute path) depending on which VirtualHost the request wants. then everything proceeds as normal. all the URLs inside the VirtualHost (or site) are still all relative...
Only the path-extension/rewriting part needs a central dictionary.
yes.
Does it really need to be invisible to non-managers, or is it enough that they can't mess with it? Only users with "Add new <whatever>" permissions on a folder should be allowed to view/change/delete the <whatever> object.
yes, that's true. but i wanted to make it invisible if possible, just to be cleaner. but it is not strictly necessary. by the way, it seems like you want to be able to specify multiple symbolic URLs for the site, as well as multiple IP addresses (if you use the IP address method). is that right? cheers adam -- Adam Feuer adamf@pobox.com
I've taken a quick look through the code you released (thanks!), and this prompted me to try to explain more clearly how I look at this whole issue. By the way, yours is the first Product I've read which uses the new methods for Product initialization and class registration; I didn't even know about them until I tried to understand your work :-) Adam Feuer wrote:
i don't use apache and zope together (but i should, i guess? :-)
Well, that depends on your needs. I find it very convenient to intersperse static (filesystem-based) and dynamic (Zope) content within the same URL namespace, and I use rewrite rules *very* heavily. There are (at least) three orthogonal ways in which you might want to distinguish incoming requests and decide how to serve them from Zope: o Which port/interface the request was received on o HTTP_HOST, REMOTE_USER, or other client-provided information o URL requested (almost always used, usually by ZPublisher) Any combination of these three is possible; You apparently depend heavily on the first, while I use the second. The third need not be restricted to ZPublisher's interpretation, as in my use of rewrite rules on the URL to decide between static and dynamic content. Simple 1-1 or many-1 mapping of possible values, such as you implement, handles the most popular case. Allowing arbitrary DTML or Python code to rewrite requests before they are resolved could handle any complicated scheme I can conceive of.
is one way better than the other...? i just returned the new path because it seemed like i could tread lightly on the Zope code... :-) but perhaps not...
My current (soon-to-be-released) code allows you to designate a single Zope object, which must live in the root folder, to be called for this purpose. Its return value is ignored, but it can call request methods to do its work. It can, of course, call on any number of other objects anywhere in the ZODB. Once the rewriting is done, and resolution of the URL begins, *we aren't done*. I can't tell from your posts whether you are aware of this, but I didn't see it in the code. Consider a request for '.../a/b/c', where '...' is handled by the rewriting rules (IP/port or HOST, doesn't matter), which decide that this request is for Zope path '/site1/a/b/c'. This will work fine, as long as the rendering process never refers to URLn, BASEn, or x.absolute_url(). Unfortunately, these are very useful, even critical. The management interface and many Products use these all over the place. In this scenario, if 'c' used URL2+'/d' to try to construct a reference to '.../a/d', it would instead get '.../site1/a/d'. This sort of thing result in "path bloat", where a few clicks yield '.../site1/site1/site1/site1/a/b/z'. Under Zope 1.10.3, there was a fairly simple patch which simply chopped the path additions off once they had been traversed, but this patch doesn't work in Zope 2.0, and there is a Better Way (tm). This is where SiteRoots come in. They fix up the URL data in the request as the site root is traversed. A 'site root' is just a traversable object which is meant to be the target of one or more rewrite rules. In the example scenario, 'site1' would be a site root, and would replace '.../site1' with '...' as a URL passed through it. Note that a SiteRoot can't tell whether a particular request has been rewritten with that SiteRoot in mind, or at all. Thus a straight, unchanged request for '/site1/a/b/c' will still generate URLs like '.../a/b/c'. I'm not yet sure what, if anything, need be done about this.
Quoting Evan Simpson <evan@4-am.com>:
Allowing arbitrary DTML or Python code to rewrite requests before they are resolved could handle any complicated scheme I can conceive of.
evan, yes, this is what i was thinking of with the Mapper.py module-- which is currently very primitive and (probably) un-Zope-like.
My current (soon-to-be-released) code allows you to designate a single Zope object, which must live in the root folder, to be called for this purpose. Its return value is ignored, but it can call request methods to do its work. It can, of course, call on any number of other objects anywhere in the ZODB.
ok, this is what i intended the Mapper to be-- a central place to register methods that implement the re-write rules. i envisioned this object living in the control panel of the VirtualHostFolder product, but the Root object seems good too. haven't built a good interface for it yet.
Once the rewriting is done, and resolution of the URL begins, *we aren't done*. I can't tell from your posts whether you are aware of this, but I didn't see it in the code.
ahhh, no i don't know this. (!) i am pretty new to Zope, and haven't tested out the DTML vars URLn, BASEn, etc. :-) thanks for pointing this out.
Consider a request for '.../a/b/c', where '...' is handled by the rewriting rules (IP/port or HOST, doesn't matter), which decide that this request is for Zope path '/site1/a/b/c'. This will work fine, as long as the rendering process never refers to URLn, BASEn, or x.absolute_url(). Unfortunately, these are very useful, even critical. The management interface and many Products use these all over the place.
understood.
This is where SiteRoots come in. They fix up the URL data in the request as the site root is traversed. A 'site root' is just a traversable object which is meant to be the target of one or more rewrite rules. In the example scenario, 'site1' would be a site root, and would replace '.../site1' with '...' as a URL passed through it.
ok, i can prbobably make VirtualHostFolders do that too. as they are being traversed, they change the request variables to match the correct URL.
Note that a SiteRoot can't tell whether a particular request has been rewritten with that SiteRoot in mind, or at all. Thus a straight, unchanged request for '/site1/a/b/c' will still generate URLs like '.../a/b/c'. I'm not yet sure what, if anything, need be done about this.
well, that is an issue in my software too-- if HTTP_HOST is set to a site in the VirtualHostFolder mapping dictionary, the URL gets rewritten. one thing i haven't managed to do is add an object (or another product) to the VirtualHostFolder control panel object at installation time. the rewrite object that you plan to place in the Root object... do you do this automatically? or does the administrator have to do this?? i'm looking forward to see your take on virtual hosting! cheers adam -- Adam Feuer adamf@pobox.com
Adam Feuer wrote:
o VirtualHostFolders derive from the Folder Object
-- with an additional property, IPaddress (this will eventually be a list of IPaddresses?)
o Small patch to ZServer.HTTPRequest -- so it places the actual socket IP and Port numbers into the request's environment (HTTP_SOCKET_IP and HTTP_SOCKET_PORT)
-- i didn't use HTTP_HOST for mapping since it is symbolic; i wanted to have a 1:1 mapping from IP address to path
At least leave an option to use HTTP_HOST, as many sites are using NamedVirtualHosts - I do it all the time with Apache.
o new persistent Remapper object -- holds dictionary of IP:path_prefix mappings -- Issue: how and where to store this, since it needs to be notifies upon creation or deletion or changes to VirtualHostFolders,
Should probably be a property of your VirtualFolder class/product (as opposed to an instance) ...
whatever way is eventually chosen, i think virtual hosting is a Good Thing and will help make Zope better and better... :-)
Amen! ------------------ Hannu
-- i didn't use HTTP_HOST for mapping since it is symbolic; i wanted to have a 1:1 mapping from IP address to path
At least leave an option to use HTTP_HOST, as many sites are using NamedVirtualHosts - I do it all the time with Apache.
hannu, this is coming.
o new persistent Remapper object Should probably be a property of your VirtualFolder class/product (as opposed to an instance)
yes, i need to store the Remapper object in the VirtualFolder Product... but i haven't figured out a good way to do this. i'll post the code, and then perhaps somebody can help out with this! :-) cheers adam -- Adam Feuer adamf at pobox.com (replace the 'at' with '@' to contact me via email) http://www.pobox.com/~adamf/
Hmmm. this sounds like an idea I've been toying with too.. I wasn't going to do a Product, tho. I was intending to do some deep level hackery to Zope itself to add a VirtualHosts item to Zope's Control Panel. This would have two tables. The first mapping vhost names to Zope paths, the second mapping physical (IP) addresses to vhost names (I.e. saying 'If there is no HTTP_HOST for ip x.y.z.w, use foo.bar.com' _OR_ 'for requests coming in on ip 1.2.3.4 _always_ use bar.baz.com, no matter what HTTP_HOST says') The mapping rules in the two tables could be made protocol specific too, so a given vhost alias could affect HTTP requests, but not FTP requests, for example. (or have one alias map http://bar.com to /users/bar and another map ftp://bar.com to /users/bar/PublicFiles using ZServer) PS: Annoying Zope nit. did you know that you can't bind ZServer's FTP channel to a specific IP ?! At least not last I looked. HTTP yes, but not FTP. -The Dragon De Monsyne
I had some further thoughts on rewriting/vhosting within Zope. I'd like to provide fairly powerful rules, on the order of those provided by Apache. My first impulse was to design AccessRule objects, which could be combined and nested to implement the rules, but then I changed my mind. Zope already has fairly powerful logic available through its Methods. If Request objects are given the setSite method you mention, and regular expressions are made available, then ordinary DTML- or Python- Methods could be used to implement rewrite rules. Perhaps it would be enough to single out an object to be called at the start of each request. The Request object would be passed into it, containing the environment/HTTP variables and other stuff available at this point. There would be no PARENTS in the Request, and no namespace. All the method would do is examine the variables and possibly call a method of the Request to change PATH_INFO. Example: <dtml-if "REQUEST['HTTP_HOST']=='site1.com'"> <dtml-call "REQUEST.setPath('/here/there/site1/'+REQUEST['PATH_INFO'])"> <dtml-elif "REQUEST['HTTP_HOST']=='site2.com"> <dtml-call "REQUEST.setPath('/another/place/site2/'+REQUEST['PATH_INFO'])"> </dtml-if> or with a PythonMethod (my personal preference <wink>): global vhosts if not globals().has_key('vhosts'): vhosts = {'site1.com': '/here/there/site1/', 'site2.com': '/another/place/site2'} new_path = vhosts.get(REQUEST['HTTP_HOST'], None) if new_path is not None: REQUEST.setPath(new_path + REQUEST['PATH_INFO'] In either case, there could be SiteRoot objects in the resulting paths which would fix up the logical URLs, once traversed. Also, providing access in the rewriter to ts_regex or re (through a temporary attribute of REQUEST?) would be very cool. ----- Original Message ----- From: Jim Fulton <jim@digicool.com>
http://www.zope.org/Members/jim/SiteObjectProposal
Comments?
folks, ok, enclosed is that VirtualHostFolder product i mentioned-- 0.0.1, a *very* preliminary release. it does mapping Virtual Hosting by Site Name and/or IP address. this code is also available on my home page at: http://www.pobox.com/~adamf/VHF-0.0.1-with-patchfile.tar.gz please treat this as an experiment-- it's got some severe kludges in it, and i haven't tested it very well. and i'm pretty new to Zope. so there. :-) if this can be used as a basis for Zope's Virtual Hosting features, great. if it just ends up as an example of how *not* to do Virtual Hosting, that's cool too. a couple of notes: the tar.gz file has two files in it, the VirtualHostFolder-0.0.1 product, and a patchfile. you install the product as usual, the patchfile needs to be applied to zope to enable the product to work. instructions for applying the patchfile are in the product's README.txt file. this product has some severe limitations-- it stores the persistent map of {SiteNames/IPaddresses : path_prefixes} in its own private ZODB database in the Zope data_dir (usually var/). i want to put this storage object in the Zope database, but i haven't figured out how yet. if someone knows how, let me know, or just have at it! the file Mapper.py (in lib/python/ZPublisher) is new, and it is just a registration facility to allow Publish to find the path remapper functions. this has limitations too; the order in which the path remap functions operate on the paths can't be specified or changed. and there are probably other no-nos that i don't know about. check out the code to see what's going on. cheers adam ps. this Product is dedicated to paul everitt and amos latteier, who both gave inspiring talks about Zope that i went to recently. thanks! :-) -- Adam Feuer adamf@pobox.com
On Tue, Sep 21, 1999 at 08:23:26PM -0700, Adam Feuer wrote:
folks,
ok, enclosed is that VirtualHostFolder product i mentioned-- 0.0.1, a *very* preliminary release. it does mapping Virtual Hosting by Site Name and/or IP address.
I'm trying it out, and already found a bug :-) Your code assumes HTTP_HOST has a port number. If it doesn't, the pages just won't display (``unpack list of wrong size'' on the string.split call). Quick fix: --- Remapper.py.orig Tue Sep 21 22:12:33 1999 +++ Remapper.py Fri Sep 24 05:50:26 1999 @@ -80,7 +80,12 @@ # try HTTP/1.1 Host header identification first http_host = request.get('HTTP_HOST') if http_host != None: - requestedSite,requestedPort=string.split(http_host,':') + host_info=string.split(http_host,':') + requestedSite=host_info[0] + if len(host_info)=1 + requestedPort='80' + else: + requestedPort=host_info[1] #print "remap- requestedSite %s" % requestedSite try: path_prefix=self.root[requestedSite] It's not pretty, but it's how I usually handle string.split. Perhaps I'll bother Guido about adding a ``minsplit'' parameter to string.split on a future version. []s, |alo +---- -- I am Lalo of deB-org. You will be freed. Resistance is futile. http://www.webcom.com/lalo mailto:lalo@webcom.com pgp key in the web page Debian GNU/Linux -- http://www.debian.org
Of course I had to blow it up.
+ if len(host_info)=1
The correct patch is: --- Remapper.py.orig Tue Sep 21 22:12:33 1999 +++ Remapper.py Fri Sep 24 05:50:26 1999 @@ -80,7 +80,12 @@ # try HTTP/1.1 Host header identification first http_host = request.get('HTTP_HOST') if http_host != None: - requestedSite,requestedPort=string.split(http_host,':') + host_info=string.split(http_host,':') + requestedSite=host_info[0] + if len(host_info)==1: + requestedPort='80' + else: + requestedPort=host_info[1] #print "remap- requestedSite %s" % requestedSite try: path_prefix=self.root[requestedSite] []s, |alo +---- -- I am Lalo of deB-org. You will be freed. Resistance is futile. http://www.webcom.com/lalo mailto:lalo@webcom.com pgp key in the web page Debian GNU/Linux -- http://www.debian.org
On Fri, 24 Sep 1999, Lalo Martins wrote:
On Tue, Sep 21, 1999 at 08:23:26PM -0700, Adam Feuer wrote:
folks,
ok, enclosed is that VirtualHostFolder product i mentioned-- 0.0.1, a *very* preliminary release. it does mapping Virtual Hosting by Site Name and/or IP address.
I'm trying it out, and already found a bug :-)
Your code assumes HTTP_HOST has a port number. If it doesn't, the pages just won't display (``unpack list of wrong size'' on the string.split call).
Quick fix:
--- Remapper.py.orig Tue Sep 21 22:12:33 1999 +++ Remapper.py Fri Sep 24 05:50:26 1999 @@ -80,7 +80,12 @@ # try HTTP/1.1 Host header identification first http_host = request.get('HTTP_HOST') if http_host != None: - requestedSite,requestedPort=string.split(http_host,':') + host_info=string.split(http_host,':') + requestedSite=host_info[0] + if len(host_info)=1 + requestedPort='80' + else: + requestedPort=host_info[1] #print "remap- requestedSite %s" % requestedSite try: path_prefix=self.root[requestedSite] What about: if not ':' in http_host: http_host=http_host+":80" requestedSite,requestedPort=string.split(http_host,':',1) string.atoi(requestedPort) # verify that the port is numeric.
Andreas -- Andreas Kostyrka | andreas@mtg.co.at phone: +43/1/7070750 | phone: +43/676/4091256 MTG Handelsges.m.b.H. | fax: +43/1/7065299 Raiffeisenstr. 16/9 | 2320 Zwoelfaxing AUSTRIA
On Fri, Sep 24, 1999 at 12:13:41PM +0200, Andreas Kostyrka wrote:
What about: if not ':' in http_host: http_host=http_host+":80"
Yes, fine too I think :-) []s, |alo +---- -- I am Lalo of deB-org. You will be freed. Resistance is futile. http://www.webcom.com/lalo mailto:lalo@webcom.com pgp key in the web page Debian GNU/Linux -- http://www.debian.org
Quoting Lalo Martins <lalo@webcom.com>:
I'm trying it out, and already found a bug :-)
Quoting Lalo Martins <lalo@webcom.com>:
I'm trying it out, and already found a bug :-)
lalo, fantastic! :-) thanks for the patch, too. (i did say it was an early release!) i'll fix it and put out an update; i also hope to work out some of the problems that evan mentioned. cheers adam -- Adam Feuer adamf@pobox.com
Adam, I'm having a problem with acquisition and VHF. I have a VHF named ``cosmetica'' that responds for ``cosmetica.gf.com.br'' (internally). When I access stuff there, it starts to resolve to ``cosmetica.com.br/cosmetica/cosmetica/cosmetica/stuff'' (one extra ``cosmetica/'' component is added for each link I click). Squishdot also has some minor problems with images and acquisition, so adding the two I end up completely busting caches :-) Any hints on why is this happening? []s, |alo +---- -- I am Lalo of deB-org. You will be freed. Resistance is futile. http://www.webcom.com/lalo mailto:lalo@webcom.com pgp key in the web page Debian GNU/Linux -- http://www.debian.org
Quoting Lalo Martins <lalo@webcom.com>:
Adam, I'm having a problem with acquisition and VHF. I have a VHF named ``cosmetica'' that responds for ``cosmetica.gf.com.br'' (internally). When I access stuff there, it starts to resolve to ``cosmetica.com.br/cosmetica/cosmetica/cosmetica/stuff'' (one extra ``cosmetica/'' component is added for each link I click). Any hints on why is this happening?
lalo, hmmmm, this is a problem discovered by evan simpson, i think. the path gets messed up because i am actually munging the path in Publish.py, instead of using __bobo_traverse__ to change the URL in the Request object. this is a bug. i believe evan's SiteRoot product doesn't have this problem... i plan to fix this, but i'm not sure if it'll be quick for me or not. :-) cheers adam -- Adam Feuer adamf@pobox.com
Jim Fulton wrote:
I've put together a proposal for hosting vertual domains in Zope. See:
http://www.zope.org/Members/jim/SiteObjectProposal
Comments?
It seems to me, that the one issue not touched on at all is allowing additional control panels inside of SiteObjects. In many cases, you are going to want to let people create ZClasses of their own that are not part of the whole Zope installation. Other than that one quibble, this seems like an idea whose time has come. Thoughts? Michael Bernstein.
I'd like to give everyone a warning about the use of the manage_beforeDelete protocol. If you override this function to perform additional clean-up/referential integrity type tasks when an object is deleted from a folder (as you should) be warned that the implementation of manage_renameObject deletes and then adds the object with the new name. Obviously, this calls the manage_beforeDelete function with the result that the renamed object will not be the same as the original object depending on what your manage_beforeDelete does. For example, assume you have implemented a simple calendar product that interacts with a contact list to enable you to schedule calls to a particular contact and that as part of deleting a contact, you remove all scheduled items for that contact (as you must, to avoid orphan schedule objects). If you then rename the contact using manage_renameObject either from the management screens or programmatically, you'll end up with a contact with no associated schedules. A similar issue exists when pasting an object via manage_pasteObject and when using WebDav to move an object. My current workaround involves overriding _notifyOfCopyTo, setting an internal flag which is checked in manage_beforeDelete before any cleanup is done and reset on exit from this function. However, I believe _notifyOfCopyTo is being replaced by manage_afterClone as _notifyOfCopyTo is not called in the WebDav code but it is in the CopySupport code. This solution should probably be generalised and incorporated into Zope so that this issue can be avoided. Does anyone have any thoughts on a general solution? Maybe the combination of manage_beforeDelete, manage_afterAdd and manage_afterClone is insufficient and needs to be extended either by additional parameters or function calls. Robert Leftwich
participants (11)
-
Adam Feuer -
Adam Feuer -
Andreas Kostyrka -
Evan Simpson -
Evan Simpson -
Hannu Krosing -
Jim Fulton -
Lalo Martins -
Michael Bernstein -
Robert Leftwich -
The Dragon De Monsyne