| *** hazmat_ has joined #zope3-dev | 00:27 | |
| JoaoJoao | how do I programatically create a new sqlos object inside a container | 00:36 |
|---|---|---|
| *** zagy has joined #zope3-dev | 00:52 | |
| *** zagy has quit IRC | 01:00 | |
| JoaoJoao | how do I commit my changes in Z3? | 01:04 |
| JoaoJoao | (the transaction) | 01:04 |
| *** yota has quit IRC | 01:08 | |
| *** projekt01 has joined #zope3-dev | 01:09 | |
| benji | JoaoJoao, I have to go, but if memory serves, just do "import transaction" and then "transaction.commit()" | 01:15 |
| *** benji has quit IRC | 01:15 | |
| projekt01 | srichter, ayt? | 01:34 |
| *** sashav has quit IRC | 01:50 | |
| projekt01 | srichter, there is a bug in XMLRPC and apidoc | 02:02 |
| *** MiUlEr has joined #zope3-dev | 02:13 | |
| JoaoJoao | if I want to add an object to a container is object['newobjid'] = mycontainerobj the only way? | 02:13 |
| projekt01 | container.__setitem__('name', obj) | 02:13 |
| projekt01 | which is called if you use: container['name'] = obj | 02:14 |
| JoaoJoao | projekt01: okay, it's just that sqlos doesn't care about the id I give, it renames it | 02:16 |
| projekt01 | Perhaps there is a name chooser involved? | 02:16 |
| JoaoJoao | projekt01: maybe I can just set the name in the afterAdd event | 02:17 |
| JoaoJoao | 'afterAdd' -> objectaddedevent | 02:17 |
| projekt01 | Do you have already a object with the same name in the container? | 02:17 |
| JoaoJoao | projekt01: No, but it gives the objects names like 'sqlquezt.Pergunta.4' | 02:18 |
| projekt01 | the name is not ignored normaly, except the container have it's own name chooser where chooses or changes the given name | 02:19 |
| JoaoJoao | that's the case in sqlos I believe | 02:19 |
| JoaoJoao | how could I override the name chooser? | 02:20 |
| projekt01 | I don't know sqlos, but I'm pretty shure there is a name chooser involved if you get another name after container['name] = object for the object.__name__ | 02:21 |
| projekt01 | Did you implement a own container? | 02:21 |
| projekt01 | Or is it a part of sqlos? | 02:22 |
| JoaoJoao | I implemented my own containers | 02:22 |
| projekt01 | can you paste the class code and the configure.zcml? | 02:23 |
| JoaoJoao | http://pastebin.com/447807 | 02:29 |
| projekt01 | can you paste the code of: SQLObjectContainer | 02:30 |
| projekt01 | and perhaps the interface of this class? | 02:30 |
| JoaoJoao | the class: http://pastebin.com/447811 | 02:31 |
| projekt01 | There is a name chooser: SQLObjectNameChooser | 02:32 |
| JoaoJoao | ahhh now I see it | 02:32 |
| *** Volpe has quit IRC | 02:32 | |
| projekt01 | did you understand it? | 02:32 |
| projekt01 | I guess the namechooser will get a utility with the given name. | 02:33 |
| JoaoJoao | it gets the factory name and puts ".<id>" | 02:33 |
| projekt01 | I guess this is for the DB connection or something like that | 02:33 |
| JoaoJoao | to avoid name conflicts | 02:33 |
| projekt01 | No | 02:33 |
| projekt01 | I guess, but I'm not sure. The name is used as the registered utility name | 02:33 |
| projekt01 | So there has to be a utility for each name | 02:34 |
| projekt01 | See: factory = zapi.getUtility(IISQLObject, name, context=self.context) | 02:34 |
| projekt01 | As far as I can see there is a named IISQLObject utility | 02:35 |
| projekt01 | is this correct, you like to store IISQLObjects in this container? | 02:35 |
| JoaoJoao | yes, I have a specific folder for my package, and in the ObjectAddedEvent I add a container for each sqlobject type | 02:37 |
| projekt01 | Ok, that's to specific for me, I don't know sqlos. | 02:39 |
| projekt01 | I hope I could point you to the right direction. | 02:39 |
| JoaoJoao | projekt01: Can I change the name chooser for my object? | 02:40 |
| projekt01 | Yes, you can do this. Register a own name chooser to a more specific interface form your container. | 02:40 |
| projekt01 | I guess this whould be: IQuestionarioContainer | 02:41 |
| projekt01 | right? | 02:41 |
| projekt01 | But make sure that you understand the part in SQLObjectNameChooser | 02:42 |
| projekt01 | I don't really know what's happen there excatly | 02:42 |
| projekt01 | Perhaps there are doctests where will give you a overview | 02:43 |
| JoaoJoao | it seems that sqlos requires the name to be that way, so | 02:55 |
| *** Theuni has joined #zope3-dev | 02:57 | |
| *** romanofski is now known as rom|ZZZ | 03:03 | |
| *** Theuni has quit IRC | 03:17 | |
| *** MiUlEr has quit IRC | 03:20 | |
| JoaoJoao | I'm trying to add an object to the container after a submit in a view: http://deadbeefbabe.org/paste/2305 | 03:38 |
| JoaoJoao | but it's not doing anything | 03:38 |
| projekt01 | try to use: self.request.get('acao', None) | 03:48 |
| projekt01 | what's that? def __init__(self,context,request,base_url=''): | 03:48 |
| projekt01 | is this a BrowserView class? | 03:48 |
| projekt01 | where did you get the base_url? I guess this isn't used. | 03:49 |
| JoaoJoao | this is a BrowserView, yes | 03:49 |
| JoaoJoao | Just removed the base_url :P | 03:49 |
| *** andres_ has joined #zope3-dev | 03:50 | |
| projekt01 | Ok, are you sure you you get the 'acao' value? | 03:50 |
| projekt01 | from the request? | 03:50 |
| *** andres has quit IRC | 03:50 | |
| JoaoJoao | yes, I made it raise an Exception at the end of the if statement | 03:50 |
| projekt01 | And you like to store a Questionario | 03:52 |
| JoaoJoao | precisely | 03:52 |
| JoaoJoao | in the 'questionarios' container | 03:52 |
| projekt01 | in a container called 'new' where is contained in the container where your view is shown? | 03:52 |
| JoaoJoao | new is supposed to be the new object name | 03:53 |
| projekt01 | Ah, I see the container is called 'questionaries' and the object is called 'new' | 03:53 |
| projekt01 | Is there a container 'questionaries' already in your container? | 03:53 |
| JoaoJoao | yes, it's always created in my SQLQueztContainer (in the ObjectAddedEvent) | 03:55 |
| projekt01 | I don't see what's wrong, this should work as far as I see. | 03:55 |
| projekt01 | No traceback? | 03:56 |
| projekt01 | No error? | 03:56 |
| JoaoJoao | No errors | 03:56 |
| JoaoJoao | damn, there was a wrong import in my view | 04:00 |
| projekt01 | ;-) | 04:01 |
| JoaoJoao | now it works like a charm | 04:01 |
| projekt01 | cool | 04:01 |
| JoaoJoao | I just wished sqlos didn't make me use <factory>.<id> names | 04:01 |
| JoaoJoao | now I'll need to make some Ajaxy stuff | 04:03 |
| projekt01 | JoaoJoao, why not Ajaj | 04:12 |
| JoaoJoao | Ajaj, much better in fact | 04:16 |
| JoaoJoao | now I just need to understand this resources thing | 04:16 |
| projekt01 | Did you know about the jsonserver implementation form Jim Washington? | 04:19 |
| JoaoJoao | yes, I've even been using as the JSON-RPC server for a Palm/PocketPC sync application | 04:20 |
| projekt01 | srichter, ayt? | 04:21 |
| projekt01 | Are you interested in a different json javascript library then jsolait? | 04:22 |
| JoaoJoao | I thought about Mochikit | 04:23 |
| projekt01 | Ok, tell me if this will work for you. | 04:24 |
| projekt01 | I added a base library for handle json via a xmlhttp request. But there is no other Ajax stuff implemented. | 04:25 |
| projekt01 | svn://svn.tiks.org/repos/Tiks/trunk/src/tiks/javascripts/json | 04:25 |
| projekt01 | depends on: svn://svn.tiks.org/repos/Tiks/trunk/src/tiks/javascripts/xmlhttp | 04:26 |
| JoaoJoao | I'll take a look, thanks | 04:27 |
| projekt01 | Ok. let me know if you use it or if you have questions. | 04:28 |
| JoaoJoao | projekt01: What is the equivalent to "javascript_slot" in Z3? | 04:33 |
| * JoaoJoao lost in this resource think | 04:45 | |
| JoaoJoao | thing | 04:45 |
| projekt01 | There is a viewlet concept imlemented in zope.viewlet where is used in the Boston skin. Try http://localhost:8080/++skin++Boston | 04:48 |
| newpers | hi projekt01 | 04:49 |
| projekt01 | hi, newpers | 04:49 |
| *** natea has quit IRC | 05:03 | |
| JoaoJoao | projekt01: I need to register the whole mochikit directory | 05:04 |
| projekt01 | I have no idea, that was the reason why I wrote a own library. | 05:05 |
| JoaoJoao | I tried resourceDirectory | 05:05 |
| projekt01 | Yes, that is the starting point. | 05:06 |
| JoaoJoao | and then e.g. /@@/mochikit/lib/Mochikit/Mochikit.js | 05:06 |
| JoaoJoao | I registered the directory for the "default" layer | 05:06 |
| *** hazmat_ has quit IRC | 05:20 | |
| projekt01 | JoaoJoao, that should work | 05:22 |
| *** projekt01 has quit IRC | 05:24 | |
| JoaoJoao | ah resourceDirectory doesn't support subdirectories | 05:39 |
| JoaoJoao | damn | 05:39 |
| JoaoJoao | this is terrible | 05:40 |
| *** JoaoJoao has quit IRC | 05:43 | |
| *** stub has joined #zope3-dev | 06:16 | |
| *** stub has quit IRC | 07:04 | |
| *** natea has joined #zope3-dev | 07:13 | |
| *** stub has joined #zope3-dev | 07:48 | |
| *** natea_ has joined #zope3-dev | 08:56 | |
| *** natea has quit IRC | 09:07 | |
| *** natea_ has quit IRC | 09:50 | |
| *** rom|ZZZ is now known as romanofski | 10:34 | |
| romanofski | moin | 10:34 |
| *** Theuni has joined #zope3-dev | 10:45 | |
| *** d2m has joined #zope3-dev | 10:54 | |
| *** sashav has joined #zope3-dev | 11:13 | |
| *** _agroszer has joined #zope3-dev | 11:21 | |
| *** Theuni has quit IRC | 11:35 | |
| *** natea has joined #zope3-dev | 11:37 | |
| *** dobee has joined #zope3-dev | 11:46 | |
| *** natea is now known as natea|zZz | 12:02 | |
| *** BjornT_ has quit IRC | 14:30 | |
| *** BjornT has joined #zope3-dev | 14:31 | |
| *** mgedmin has joined #zope3-dev | 14:53 | |
| *** yota has joined #zope3-dev | 14:56 | |
| *** sashav has quit IRC | 15:08 | |
| *** projekt01 has joined #zope3-dev | 15:10 | |
| projekt01 | srichter, ayt? | 15:11 |
| *** sashav has joined #zope3-dev | 15:15 | |
| *** BjornT has quit IRC | 15:19 | |
| *** BjornT has joined #zope3-dev | 15:19 | |
| *** sashav has quit IRC | 15:25 | |
| *** BjornT has quit IRC | 15:27 | |
| *** BjornT has joined #zope3-dev | 15:27 | |
| *** _agroszer has quit IRC | 15:42 | |
| *** _agroszer has joined #zope3-dev | 16:21 | |
| *** andres_ has quit IRC | 16:37 | |
| *** Jasper has joined #zope3-dev | 16:42 | |
| Jasper | hey | 16:42 |
| *** Jasper has quit IRC | 16:57 | |
| *** sashav has joined #zope3-dev | 17:17 | |
| *** MacYET__ has joined #zope3-dev | 17:19 | |
| *** J1m has joined #zope3-dev | 17:27 | |
| *** bradallen has joined #zope3-dev | 17:28 | |
| *** philiKON has joined #zope3-dev | 17:37 | |
| *** _agroszer is now known as agroszer | 17:37 | |
| *** sashav_ has joined #zope3-dev | 17:42 | |
| *** sashav has quit IRC | 17:42 | |
| *** sashav_ is now known as sashav | 17:42 | |
| *** sashav has quit IRC | 17:45 | |
| *** sashav has joined #zope3-dev | 17:59 | |
| *** MrTopf has joined #zope3-dev | 18:05 | |
| J1m | Anybody wanna argue about layers? ;) | 18:11 |
| *** sashav has quit IRC | 18:15 | |
| MacYET__ | layers? | 18:18 |
| *** MJ has quit IRC | 18:18 | |
| J1m | Yup | 18:18 |
| MacYET__ | in which context? | 18:19 |
| J1m | zope 3 :) | 18:19 |
| MacYET__ | sorry, i don't get it :) | 18:20 |
| J1m | IN particular, the notion of "default layer" seems rather confused. | 18:20 |
| J1m | Then you don't have to argue about it. :) | 18:20 |
| MacYET__ | sorry, i read 'lawyer' | 18:21 |
| MacYET__ | :) | 18:21 |
| J1m | :) | 18:21 |
| philiKON | J1m, hey | 18:21 |
| J1m | hey | 18:21 |
| philiKON | i found the default layer a bit annoying too | 18:22 |
| philiKON | when i ported five to zope 3.2 | 18:22 |
| J1m | Any idea wtf default layers are supposed to be about? | 18:22 |
| J1m | Fortunately, they don't seem to "work", for some definition of "work". | 18:23 |
| philiKON | for example? | 18:23 |
| J1m | The intent seem to be that you can say: "when a directive doesn't mention a layer, use the default layer, which is defined by another directive". | 18:24 |
| J1m | But the implementation of this is totally broken. | 18:24 |
| philiKON | yeah | 18:24 |
| J1m | and 444 complains about this. | 18:24 |
| philiKON | dunno the bugs actually | 18:25 |
| philiKON | but i think it's not needed really | 18:25 |
| philiKON | the browser:defaultLayer directive | 18:25 |
| J1m | well, it just doesn't work. | 18:25 |
| philiKON | ic | 18:25 |
| philiKON | well, i think i know why | 18:25 |
| philiKON | because the directive handlers default to layer=IDefaultLayer | 18:25 |
| philiKON | it's as simple as that | 18:25 |
| J1m | The implementation is broken for at least 2 reasons. | 18:25 |
| philiKON | i really think we could get rid of IDefautLayer | 18:25 |
| philiKON | make it IBrowserRequest | 18:25 |
| J1m | OK 3 reasons. ;) | 18:26 |
| J1m | The default layer *is* basically the type. | 18:26 |
| philiKON | ;) | 18:26 |
| J1m | Since that is the usuall fallback. | 18:26 |
| J1m | usual | 18:26 |
| J1m | It's a mess. | 18:27 |
| philiKON | don't know what you mean by the default layer is the type... | 18:27 |
| J1m | well, it depends on the code you are looking at. | 18:27 |
| J1m | The code in zope.app.component.metaconfigure falls back to presentation type. | 18:27 |
| J1m | (basically a request type) | 18:27 |
| J1m | The code in zope.app.publisher defines an IDefaultLayer that extends IBrowserRequest. | 18:28 |
| J1m | It might as well ise IBrowserRequest. | 18:28 |
| * projekt01 layers are very useful but I agree on simplify this part. | 18:28 | |
| J1m | I suppose there is a proposal somewhere ... | 18:29 |
| philiKON | J1m, let's get rid of IDefaultLayer, make IBrowserRequest the default | 18:29 |
| philiKON | and get rid of browser:defaultLayer | 18:29 |
| philiKON | since it doesn't work anyway | 18:29 |
| J1m | That's what I'm leaning toward. | 18:29 |
| J1m | But probably for 3.2. | 18:29 |
| J1m | I mean 3.4 | 18:30 |
| * philiKON hopes you mean 3.3 | 18:30 | |
| J1m | I'm inclined to mark the "feature" permanently broken. | 18:30 |
| J1m | And deprecate the directive. | 18:30 |
| projekt01 | J1m, you mean only browser:defaultLayer and not the layers at all? | 18:30 |
| J1m | which means we can't actually remove it until 3.4. | 18:30 |
| philiKON | right, right | 18:31 |
| J1m | projekt01, no, layers are fine. | 18:31 |
| projekt01 | Ok, I agree on this | 18:31 |
| J1m | Just the broken default layer concept. | 18:31 |
| projekt01 | ok | 18:31 |
| philiKON | J1m, btw, now that we're using interfaces for layers and skins, I don't understand why we need to separate between skins and layers as a concept | 18:32 |
| philiKON | as separate concepts i mean | 18:33 |
| J1m | perhaps we don't. | 18:33 |
| projekt01 | philiKON, we use layers for regsiter views on it and the skin is a package where has dependency on layers, but the views don't have dependency to skins. | 18:33 |
| philiKON | projekt01, right, nothing would change there | 18:34 |
| philiKON | except that everythiing would be skins | 18:34 |
| projekt01 | This allows you to develop a package including a layer where others can use in their skin | 18:34 |
| philiKON | layers and skins would all be skins | 18:34 |
| philiKON | skins could extend IInterface or other skins | 18:34 |
| projekt01 | Then you have to inherit from this skin | 18:34 |
| projekt01 | Ah, Ok | 18:34 |
| philiKON | err, skins could extend Interface or other skins | 18:34 |
| * philiKON proposes to consolidate layers + skins into one concept | 18:36 | |
| projekt01 | Ok, this sounds good, we have only to make sure that we have a concept where we don't have to inherit skin for get registered views form another skin (layer) | 18:36 |
| projekt01 | philiKON, +1 | 18:36 |
| philiKON | not sure what you mean by that sentence | 18:37 |
| projekt01 | We have to offer a (layer) where we can register views and make sure that somebody can use this (layer) in his custom skin | 18:38 |
| projekt01 | That's the target of the layer - skin concept, separate the registration (layer) and the (implementation) skins | 18:40 |
| projekt01 | Or not? | 18:40 |
| philiKON | not really | 18:40 |
| philiKON | at least not for me | 18:40 |
| philiKON | the idea of layers is that you can override views from a "lower" layer | 18:40 |
| philiKON | let's take this example: | 18:41 |
| philiKON | i want to override the @@contents.html view | 18:41 |
| philiKON | for my skin | 18:41 |
| philiKON | somebody who deploys a site is looking to customize the default skin | 18:41 |
| philiKON | so, right now he has to make a new layer | 18:41 |
| philiKON | register the @@contents.html view for that layer | 18:41 |
| philiKON | and then make a skin | 18:41 |
| philiKON | composed of the default layer, the layer of the default skin (e.g. 'rotterdam') and then his own custom layer | 18:42 |
| philiKON | that's a lot of clutter | 18:42 |
| philiKON | what if you'd only have to make a new skin from the skin you're trying to customize | 18:43 |
| philiKON | and you can register your views for that skin directly | 18:43 |
| philiKON | that's what i'm msotly looking at | 18:43 |
| philiKON | </over> | 18:43 |
| projekt01 | Yes, but it's also a useful concept for a better separation. Right now I'm able to offer layers and register components without to have dependency to the skin implementation. | 18:44 |
| philiKON | i'm not sure if i understand that | 18:45 |
| philiKON | what are you offering in these layers that couldn't be "offered" in the 'default' layer? | 18:46 |
| *** J1m has quit IRC | 18:46 | |
| philiKON | and what's a skin "implementation"? | 18:46 |
| *** MacYET__ has left #zope3-dev | 18:46 | |
| projekt01 | I like the registration level which layers offer. This allows us to inherit a layer in a skin without to inherit the skin at all. Because most skin will also define images, javascript, etc | 18:46 |
| projekt01 | But perhaps this could be done in your simplification as well. | 18:47 |
| philiKON | yeah, my simplification just merges the concepts | 18:48 |
| projekt01 | Right now we use a minimal layer or a trusted layer. There are no images or javascript registered, only traverser or important views | 18:48 |
| philiKON | it doesn't keep you form separating stuff in different skin interfaces | 18:48 |
| philiKON | ah, ok | 18:49 |
| projekt01 | I see | 18:49 |
| philiKON | so, make that a skin as well | 18:49 |
| philiKON | ITrustedFooSkin | 18:49 |
| philiKON | IFooSkin(ITrustedFooSkin) | 18:49 |
| projekt01 | Yes, I see, we don't need a layer or skin implementation for this separation. | 18:49 |
| projekt01 | or/and | 18:50 |
| philiKON | right | 18:51 |
| philiKON | canb e covered by just one concept | 18:51 |
| projekt01 | Ok, I agree | 18:51 |
| * projekt01 is going to dinner | 18:51 | |
| andrew_m | simple question: how do i link from a pagetemplate to /blah.html in a way that works with virtual hosts? | 18:51 |
| projekt01 | see you | 18:52 |
| *** projekt01 is now known as _projekt01 | 18:52 | |
| andrew_m | like <a href="???/blah.html">...</a> | 18:53 |
| andrew_m | i'm messing with @@, ++, .. but no joy | 18:54 |
| philiKON | andrew_m, with the initial slash in /blah.html you mean the virtualhost root? | 18:56 |
| andrew_m | /blah.html is a view for the root of zope, in the virtual host it might be /something/blah.html | 18:56 |
| philiKON | huh? | 18:56 |
| andrew_m | i'm basically trying to switch from http://myserver:8080 to http://myserver/something/ with apache virtual hosts | 18:58 |
| *** ignas has joined #zope3-dev | 18:58 | |
| philiKON | and why doesn't simply linking to /blah.html not work? | 18:59 |
| andrew_m | it links to /blah.html instead of /something/blah.html | 18:59 |
| philiKON | well, 'something' isn't your virtualhost root | 18:59 |
| mgedmin | philiKON, imagine an apache RewriteRule /something/(.*) http://localhost:8080/++vh++http:foo.com:80/something/++/$1 [R] | 19:00 |
| andrew_m | mgedmin: yeah, thanks | 19:00 |
| philiKON | uh, ok | 19:00 |
| philiKON | ic | 19:00 |
| andrew_m | maybe i'm trying the impossible here :/ | 19:00 |
| mgedmin | andrew_m, does your view have a reference to the root folder? | 19:01 |
| philiKON | no, i think it's quite possible | 19:01 |
| mgedmin | in that case tal:attributes="href ${view/root/@@absolute_url}/blah.html" ought to work | 19:01 |
| philiKON | andrew_m, you just don't have to put things inside a 'something' folder on the zodb side | 19:01 |
| philiKON | mgedmin, view/root ??? | 19:01 |
| andrew_m | philiKON: yes, i don't | 19:01 |
| mgedmin | the view would have to set a 'root' attribute | 19:01 |
| philiKON | ${root/@@absolute_url} i think | 19:01 |
| philiKON | root is a zpt variable | 19:02 |
| mgedmin | is there a 'root' in the default TALES namespace? | 19:02 |
| mgedmin | I didn't know that | 19:02 |
| philiKON | i bet IVirtualHostRequest also defines a method that gives you similar info] | 19:03 |
| andrew_m | hmm | 19:03 |
| andrew_m | <a tal:attributes="href ${root/@@home.html}">Back to Home.</a> | 19:03 |
| philiKON | no no no | 19:03 |
| andrew_m | PTRuntimeError: ['Compilation failed', 'zope.tal.taldefs.TALError: Invalid variable name "@@home.html}" | 19:03 |
| philiKON | ${root/@@absolute_url}/@@home.html | 19:04 |
| *** stub has quit IRC | 19:04 | |
| *** sashav has joined #zope3-dev | 19:04 | |
| andrew_m | hmm: PTRuntimeError: ['Compilation failed', 'zope.tal.taldefs.TALError: Invalid variable name "@@home.html" in expression u\'${root/@@absolute_url}/@@home.html | 19:05 |
| mgedmin | aargh, "string:${root/@@absolute_url}/@@home.html" :-) | 19:06 |
| andrew_m | KeyError: 'root' :) | 19:06 |
| philiKON | dang | 19:08 |
| philiKON | gotta reboot | 19:08 |
| *** philiKON has quit IRC | 19:08 | |
| andrew_m | ah: string:${context/@@absolute_url}/@@home.html might be working.. | 19:09 |
| andrew_m | or maybe that's not the same.. hmm | 19:09 |
| *** J1m has joined #zope3-dev | 19:12 | |
| *** natea|zZz is now known as natea|sanfran | 19:13 | |
| mgedmin | it might not be the same | 19:16 |
| mgedmin | andrew_m, what is the context of your view? | 19:16 |
| andrew_m | mgedmin: any folder | 19:16 |
| andrew_m | i guess.. it's the logout page | 19:16 |
| mgedmin | in that case you may add a function to your view class | 19:16 |
| mgedmin | def root(self): return zapi.getRoot(self.context) | 19:17 |
| mgedmin | and then use | 19:17 |
| mgedmin | aargh, "string:${view/root/@@absolute_url}/@@home.html" :-) | 19:17 |
| andrew_m | ok, i'll try that thanks | 19:17 |
| mgedmin | (the aargh bit is optional :) | 19:17 |
| andrew_m | lol | 19:18 |
| J1m | mgedmin, do you know how virtual hosting works? | 19:18 |
| J1m | Or where it is documented? | 19:18 |
| andrew_m | J1m: there's something in srichter's book, but more about configuration | 19:18 |
| mgedmin | J1m, I do | 19:19 |
| J1m | I'm trying to look at http://www.zope.org/Collectors/Zope3-dev/465. | 19:19 |
| J1m | But I don't have a firm grasp of how virtual hosting is used. | 19:20 |
| *** philiKON has joined #zope3-dev | 19:20 | |
| * J1m looks at staphans on-line book | 19:21 | |
| * mgedmin looks | 19:21 | |
| *** _projekt01 is now known as projekt01 | 19:21 | |
| * projekt01 virtualhosts work very well for me | 19:22 | |
| projekt01 | I udpated most parts of z3 for vh support e.g. xmltree, breadcrumbs etc. | 19:23 |
| projekt01 | And I use vh in production. | 19:23 |
| J1m | I wish there was a document that specified the syntax of a ++vh thing. | 19:24 |
| andrew_m | projekt01: hmm.. so how would you link to a simple URL like /home.html when using virtual hosts? | 19:25 |
| projekt01 | Issue 465 describes things like "Page "above" site root level doesn't exist | 19:25 |
| andrew_m | projekt01: from a page template that is | 19:25 |
| philiKON | J1m, there is... otherwise i couldn't have figured it out for my book ;) | 19:25 |
| J1m | philiKON, I dunno, you might have read the code. :) | 19:25 |
| mgedmin | J1m, http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/VirtualHosting | 19:26 |
| projekt01 | andrew_m, you have to write it by yourself. | 19:26 |
| mgedmin | except that the second '++' traversal element is required | 19:27 |
| J1m | ok | 19:27 |
| mgedmin | not optional, like it was in the initial proposal | 19:27 |
| projekt01 | andrew_m, what url do you mean? | 19:27 |
| J1m | so basically, when you see one of these things, you are saying that the thing before the /++/ is the virtual URL of the current object. | 19:27 |
| mgedmin | yes | 19:28 |
| andrew_m | projekt01: just any absolute URL, e.g. /home.html, a view for the root folder | 19:28 |
| J1m | I guess this gives me enough to try and reproduce the bug. | 19:28 |
| * mgedmin tries to reproduce http://www.zope.org/Collectors/Zope3-dev/465 | 19:28 | |
| projekt01 | andrew_m, Use the normal absolute URL | 19:28 |
| * J1m says "Yay!" :) | 19:29 | |
| projekt01 | andrew_m, do you try to test it without a real virtual host (apache) setup? | 19:29 |
| mgedmin | hm... skins and ++vh++ do not like each other | 19:29 |
| J1m | dang | 19:30 |
| mgedmin | http://localhost:8080/++skin++Boston/++vh++http:localhost:8080/++/zz shows me the 404 page, but not skinned properly | 19:30 |
| mgedmin | http://localhost:8080/++skin++Boston/++vh++http:localhost:8080/++skin++Boston/++/zz shows the skinned 404 page | 19:30 |
| andrew_m | projekt01: yes, well it should work with and without vh's | 19:30 |
| mgedmin | it appears that ++vh++ doesn't automatically include the skin in the generated URLs | 19:31 |
| mgedmin | but this is a different problem from 465 | 19:31 |
| J1m | yup | 19:31 |
| projekt01 | mgedmin, Does this work: http://localhost:8080/++skin++Boston/zz | 19:31 |
| andrew_m | projekt01: <a href="/home.html">Home</a> will link to /home.html and not <virtual host>/home.html | 19:31 |
| mgedmin | projekt01, it does | 19:31 |
| projekt01 | J1m, mgedmin, we use it in production. It works with apache. See http://www.ch.amadeus.com you can ensure that this is a z3 app with http://www.ch.amadeus.com/++skin++Rotterdam | 19:33 |
| mgedmin | aha! | 19:33 |
| mgedmin | I managed to reproduce the bug | 19:33 |
| mgedmin | http://localhost:8080/++skin++Boston/plugh/++vh++http:localhost:8080/++skin++Boston/++/zz gives me the proper 404 message | 19:33 |
| mgedmin | http://localhost:8080/++skin++Boston/plugh/++vh++http:localhost:8080/++/zz gives me a SystemError | 19:33 |
| mgedmin | I had to make 'plugh' a site | 19:33 |
| mgedmin | when 'plugh' was a regular folder, both URLs gave me 404 errors (but one wasn't skinned properly) | 19:33 |
| mgedmin | wait a second, I'm wrong | 19:35 |
| projekt01 | btw, this will work for me: http://localhost:8080/++skin++MySkin/somefolder/++vh++http:myskin.mydomain.com:80/++ | 19:35 |
| mgedmin | I'm wrong; I cannot reproduce the error -- I had accidentally omitted the /++/ thus causing an error in the ++vh++ handler | 19:36 |
| projekt01 | andrew_m, sure, /home.html is a absolute url path | 19:36 |
| andrew_m | projekt01: yes, that's what i am trying to solve :) | 19:37 |
| andrew_m | projekt01: i expect a solution with ${something} and probably some @@ and some ++ somewhere | 19:37 |
| J1m | mgedmin, I can't reproduce this error either. | 19:38 |
| projekt01 | andrew_m, use "./home.html" as a relative path. | 19:38 |
| J1m | Of course, there's the error you pointed out that the skin is lost. | 19:38 |
| J1m | In fact, the default skin is lost too. | 19:38 |
| andrew_m | projekt01: no good... the link can appear in some sub folder like /blah/blah/blah.html | 19:38 |
| projekt01 | andrew_m, what's the base url for home.html? | 19:39 |
| mgedmin | I do not understand the bit about the default skin being lost | 19:39 |
| andrew_m | projekt01: just /home.html (in the root (without vh's)) | 19:39 |
| projekt01 | andrew_m, register a virtualhost_url instead of a absolute_url which points to the virtual host root instead to the application root. | 19:40 |
| J1m | ugh | 19:41 |
| J1m | virtual hosting is mostly not working for me. | 19:41 |
| projekt01 | Btw, virtualhost urls get rewriten by Apache's RewriteRule directive! | 19:41 |
| mgedmin | J1m, in what way? | 19:42 |
| projekt01 | RewriteRule (/?.*) http://localhost:8080/++skin++Admin/vhosts/extranet/++vh++http:admin.amadeus.demo:80/++$1 [P,L] | 19:42 |
| mgedmin | virtual hosting works, but too complicated | 19:42 |
| J1m | My understanding is that generated URLs should be virual. | 19:42 |
| J1m | When I go to: | 19:42 |
| J1m | http://localhost:8080/++vh++http:127.0.0.1:8080/++/@@contents.html | 19:42 |
| J1m | in a fresh zope | 19:42 |
| projekt01 | Then you have problems with the HTTP server bindings since we use Twisted! | 19:43 |
| * mgedmin does that | 19:43 | |
| J1m | The links to menu items and folder items are not virtual. | 19:43 |
| mgedmin | that's because they are relative links | 19:44 |
| mgedmin | and your browser sees the ++vh++ bit | 19:44 |
| mgedmin | and there is no <base href="..." /> tag | 19:44 |
| J1m | I guess that use of ++vh++ needs to trigger that. | 19:44 |
| mgedmin | if you View Document Source, you won't find '++vh++' inside | 19:45 |
| J1m | we need to generate a base href any time the logical url doesn't match the fiven url. | 19:45 |
| projekt01 | Sorry, localhost and 127.0.0.1 works but the original IP of your computer won't | 19:45 |
| * mgedmin is completely not familiar with base href generation logic in Z3 | 19:45 | |
| J1m | mgedmin, what I just said is the guiding principle. | 19:46 |
| *** tiredbones has quit IRC | 19:47 | |
| J1m | But the virtual hosting code doesn't seem to know about this. | 19:47 |
| J1m | to see this, add a couple of items to the root folder and then go to: | 19:48 |
| J1m | http://localhost:8080/++vh++http:127.0.0.1:8080/++ | 19:48 |
| J1m | vs | 19:48 |
| J1m | http://localhost:8080/++vh++http:127.0.0.1:8080/++/ | 19:48 |
| J1m | In the second case, the logical and actual URLs match, so no base href. | 19:48 |
| J1m | In the former case, they don't, o Zope generates a base href. | 19:49 |
| mgedmin | hmm... | 19:49 |
| mgedmin | where in Z3 is the <base href> code? | 19:49 |
| J1m | zope.publisher.browser | 19:51 |
| J1m | search for base_needed | 19:51 |
| mgedmin | should the presence of ++vh++ always imply base_needed = True? | 19:52 |
| J1m | yes | 19:52 |
| projekt01 | J1m, I'm confusing. Are you suggesting that virtual host should generate ++vh++ url's? | 19:52 |
| projekt01 | This is the job of Apache!!! | 19:52 |
| J1m | mgedmin, unfortunately, the plumbing isn't clear. | 19:53 |
| J1m | projekt01, no, just the opposite. | 19:53 |
| J1m | projekt01, the urls generated by Zope need to omit the ++vh++ bit. | 19:53 |
| mgedmin | J1m, easy to do: if self.getVirtualRoot() is not None: base_needed = True | 19:53 |
| J1m | In fact, the URLs generated by zope shoudl refelect the virtual URL. | 19:54 |
| J1m | mgedmin, ah, cool | 19:54 |
| *** natea|sanfran has quit IRC | 19:54 | |
| mgedmin | see also src/zope/app/traversing/ftests/test_vhosting.py | 19:54 |
| mgedmin | there are some functional tests that look at <base> when ++vh++ is used | 19:54 |
| projekt01 | J1m, Ok | 19:55 |
| J1m | mgedmin, right, but they don't test that a base is triggered by vh. | 19:57 |
| J1m | But I suppose it would be easy to extend them to do so. | 19:57 |
| projekt01 | I don't understand why the use of ++vh++ needs a base and no virtual host not? | 19:57 |
| J1m | projekt01, did you try the examples I gave? | 19:58 |
| J1m | The problem is that virtual hosting needs to affect relative URLs too. | 19:58 |
| J1m | The only way they can do this is via base href. | 19:59 |
| *** BjornT has quit IRC | 19:59 | |
| J1m | mgedmin, I guess I'll try to update this test to make sure that base href gets triggered. | 19:59 |
| J1m | and then make it pass. | 20:00 |
| projekt01 | J1m, Where do you think will a relative url like "./home.html" end if the virtual host url points to www.foobar.com without a base url? | 20:01 |
| J1m | projekt01, did you try the examples I gave? | 20:01 |
| projekt01 | You mean this: http://localhost:8080/++vh++http:127.0.0.1:8080/++/@@contents.html | 20:02 |
| J1m | no | 20:02 |
| J1m | http://localhost:8080/++vh++http:127.0.0.1:8080/++ | 20:02 |
| J1m | vs | 20:02 |
| J1m | http://localhost:8080/++vh++http:127.0.0.1:8080/++/ | 20:02 |
| J1m | before doing that, add some items to the root folder | 20:02 |
| J1m | Then look at the links to these items with and without the trailing slash. | 20:03 |
| *** BjornT has joined #zope3-dev | 20:05 | |
| projekt01 | I don't see any difference. What should be different? My links are both time the same like: ><A href="demos">demos</A> | 20:07 |
| J1m | Look at the links your browser shows in the status bar. | 20:07 |
| projekt01 | Ups | 20:08 |
| projekt01 | where does this came form? | 20:09 |
| projekt01 | is this a request header information? | 20:09 |
| *** natea has joined #zope3-dev | 20:09 | |
| J1m | ah wait | 20:10 |
| J1m | I'm being slightly stupid. | 20:10 |
| J1m | This is an unrealistic test. | 20:10 |
| J1m | If you have apache in front of Zope, then the browser will submit virtual urls in the first place. | 20:10 |
| J1m | so this is not a problem. | 20:11 |
| projekt01 | Yes, yes | 20:11 |
| projekt01 | that's what I mean | 20:11 |
| J1m | It is only an apparent problem when tsting virtual hosting directly. | 20:11 |
| J1m | OK, then we can drop this. | 20:11 |
| projekt01 | Ok | 20:11 |
| mgedmin | well, perhaps it would help developers that try to debug other virtual hosting issues | 20:12 |
| J1m | So, now we just have the skin mangling to contend with. | 20:12 |
| mgedmin | I think this is not the first time someone saw a ++vh++ in the browser's status bar and assumed virtualhosting didn't work | 20:12 |
| J1m | mgedmin, I dunno. | 20:12 |
| J1m | But generating base hrefs is generally frowned upon. | 20:13 |
| projekt01 | but the usecase form andrew_m is different he has to call a replacement for absolute_url where returns a virtualhost url for a use in ZPT. | 20:13 |
| J1m | we don't want to generate them unless we absolutely need to. | 20:13 |
| projekt01 | J1m, I agree | 20:13 |
| mgedmin | projekt01, we were talking about http://www.zope.org/Collectors/Zope3-dev/465, not andrew's use case | 20:14 |
| mgedmin | I think | 20:14 |
| J1m | yup | 20:14 |
| projekt01 | yes | 20:14 |
| J1m | so wrt that, I can't reproduce that behaviour, but | 20:14 |
| J1m | I;m seeing rather broken skin behavior. | 20:14 |
| *** tiredbones has joined #zope3-dev | 20:15 | |
| mgedmin | it is the interaction of shiftNameToApplication and setVirtualHostRoot | 20:16 |
| mgedmin | shiftNameToApplication modifies self._app_names | 20:16 |
| mgedmin | setVirtualHostRoot overwrites self._app_names | 20:16 |
| * projekt01 the usecase form andrew_m is a important part, perhaps we should register a default virtualhost_url as a default view like absolute_url and return a absolute url or the application root url. | 20:16 | |
| *** SiggyF has joined #zope3-dev | 20:17 | |
| andrew_m | projekt01: would be cool.. i need that in lots of places.. guess i have to write a function behind every view for now | 20:17 |
| mgedmin | andrew_m, but do you want the URL of the root folder, or the URL of the site? | 20:18 |
| andrew_m | mgedmin: i didn't have the nerves to even think about sites yet (i guess i'm just using the default site (?)) | 20:19 |
| mgedmin | the root folder is a site | 20:19 |
| andrew_m | ok | 20:19 |
| andrew_m | that's the only site i have then | 20:19 |
| mgedmin | but you can make subfolders sites too | 20:19 |
| mgedmin | is there a way to access the current site from ZPT? | 20:19 |
| mgedmin | zapi:site or ++site++ or whatnot? | 20:20 |
| projekt01 | mgedmin, as far as I know can only Isite used for virtual host roots. right? | 20:20 |
| mgedmin | projekt01, I did not understand what you said | 20:20 |
| projekt01 | you can only point to a ISite as a virtual host root. | 20:21 |
| projekt01 | not a folder | 20:21 |
| mgedmin | no | 20:21 |
| mgedmin | you can point to anything as a vhost root | 20:21 |
| projekt01 | are you sure? | 20:21 |
| mgedmin | but you will need an additional rule for /@@/ to handle resources if you do so | 20:21 |
| mgedmin | I use that in production | 20:21 |
| projekt01 | Ok | 20:22 |
| projekt01 | mgedmin, good idea! | 20:22 |
| J1m | mgedmin, are you seeing the skin display messed up? | 20:23 |
| J1m | Or are you seeing the skin not reflected in the URLs? | 20:23 |
| J1m | Hm, I'm probably confused. | 20:24 |
| projekt01 | J1m, I guess it depends if you put the ++skin++ in front of ++vh++ or at the end in your url | 20:25 |
| projekt01 | both is possible | 20:25 |
| projekt01 | tha part in fornt of ++vh++ get hidden called and the part after ++vh++ get included in the real url | 20:26 |
| mgedmin | J1m, if I go to http://localhost:8080/++skin++Boston/++vh++http:127.0.0.1:8080/++/ | 20:26 |
| mgedmin | I get a page that refers to http://127.0.0.1:8080/@@/skin.css | 20:27 |
| mgedmin | while it should refer to http://127.0.0.1:8080/++skin++Boston/@@/skin.css | 20:27 |
| J1m | I don't agree. | 20:27 |
| *** philiKON has quit IRC | 20:28 | |
| projekt01 | mgedmin, the skin.css is served from the Boston skin | 20:28 |
| J1m | In this example, the ++skin++ is in the physical part pf the URL that is overwritten by the virtual part. | 20:28 |
| J1m | Presumably, it was provided by the apache rewrite rule. | 20:28 |
| J1m | so it shoudln't be included in virtual URLs, IMO. | 20:29 |
| J1m | However, when I go to that URL, the skin is messed up. | 20:29 |
| J1m | I'm guessing that if I has apache in front, I'd be OK though. | 20:30 |
| J1m | Because, as it standsm it can't find the css. | 20:30 |
| J1m | Which is, I suspect, what projekt01 was just saying. :) | 20:30 |
| J1m | I suspect I shoudln't be fooling with this without something in front rewriting things. | 20:31 |
| projekt01 | J1m, Yes, because you don't have a apache and DNS setup where is able to deliver the link http://127.0.0.1:8080/@@/skin.css | 20:31 |
| J1m | (dns wouldn't be a problem :) | 20:31 |
| projekt01 | Ok, but the missing RewriteRule inApache | 20:32 |
| J1m | yup | 20:32 |
| mgedmin | perhaps you are right | 20:32 |
| projekt01 | Note: virtual hosts are only usable with a virtual server | 20:32 |
| projekt01 | setup | 20:32 |
| J1m | Given how confuded I am, I wouldn't count on it. ;) | 20:32 |
| mgedmin | no, wait | 20:32 |
| mgedmin | if I go directly to http://localhost:8080/++skin++Boston/ | 20:33 |
| J1m | "confuded" sounds like a real word, sort of. ;) | 20:33 |
| mgedmin | then the HTML source explicitly refers to http://localhost:8080/++skin++Boston/@@/toolbar.css | 20:33 |
| mgedmin | as an absolute URL | 20:33 |
| J1m | yes | 20:33 |
| * mgedmin would hate to see ++something++ in a browser's location bar, so /me is all in favour of hiding these details in Apache's rewrite rules and never never ever seeing them in generated absolute URLs | 20:34 | |
| J1m | But suppose the user types in: | 20:34 |
| J1m | http://my.foo.org/++skin++waycool/whatever | 20:35 |
| projekt01 | mgedmin, there is no wrong output in the browser bar. This happens only because there is no Apache where delivers your real call. | 20:35 |
| J1m | to explcitly select a skin. | 20:35 |
| J1m | where my.foo.org is virtual. | 20:35 |
| J1m | The app sees: | 20:35 |
| J1m | http://localhost:8080/foo/++vh++http:my.foo.org:80/++skin++waycool/whatever | 20:36 |
| J1m | Here the skin is part of the virtual url and should be included in generated urls. | 20:37 |
| mgedmin | apparently ++skin++ must be the very first name (BrowserRequest.shiftNameToApplication requires this), so users effectively can't use ++skin++ in virtual URLs | 20:37 |
| mgedmin | you can't even do http://localhost:8080/++debug++errors/++skin++Boston/ | 20:37 |
| mgedmin | or http://localhost:8080/++debug++source/++skin++Boston/ | 20:37 |
| mgedmin | I mislike that | 20:37 |
| projekt01 | J1m, if you like to hide the skin you can use: | 20:38 |
| projekt01 | http://localhost:8080/++skin++waycool/foo/++vh++http:my.foo.org:80/whatever | 20:38 |
| J1m | http://localhost:8080/++vh++http:127.0.0.1:8080/++/++skin++Boston/contents.html | 20:38 |
| J1m | works for me | 20:38 |
| J1m | projekt01, yes, I know. | 20:38 |
| J1m | I was giving a different use case. | 20:38 |
| projekt01 | And the following will only work if the apache get setup correct: | 20:39 |
| projekt01 | http://localhost:8080/++skin++Boston/++vh++http:127.0.0.1:8080/++/contents.html | 20:39 |
| mgedmin | J1m, it works -- but only if your RewriteRule points to the root folder | 20:39 |
| mgedmin | never mind, it works in other cases as well | 20:40 |
| J1m | http://localhost:8080/aaa/++vh++http:127.0.0.1:8080/++/++skin++Boston/contents.html | 20:40 |
| mgedmin | I was mistaken | 20:40 |
| J1m | works for me too. | 20:40 |
| J1m | To be clear, there are 2 use cases: | 20:40 |
| projekt01 | J1m, but only if you have a item called 'aaa' in the root | 20:40 |
| mgedmin | well, duh | 20:41 |
| mgedmin | and also only when you have Zope 3 running on localhost port 8080 | 20:41 |
| projekt01 | ;-) | 20:41 |
| J1m | 1. You want to specify that a particular virtual site uses a particular skin. You can specify that as part of the rerwite rule before the virtual host specification. In that case, the skin is excluded from the virtual url. | 20:41 |
| * mgedmin nods | 20:42 | |
| *** BjornT has quit IRC | 20:42 | |
| *** BjornT has joined #zope3-dev | 20:42 | |
| J1m | 2. The user wants to select a skin by including ++skin++name, In this case, the skin appears after the ++vh++ thing and appears in virtual urls. | 20:42 |
| J1m | so, I don't think we have a problem. | 20:42 |
| mgedmin | good | 20:42 |
| projekt01 | Yup | 20:43 |
| WebMaven | J1m: do you have any time for a bit of blue-sky Q&A? | 20:43 |
| J1m | In addition, I can't reproduce 465, so I think I'll mark that as non-reproduceable. | 20:43 |
| J1m | so I think we're ready for a beta! | 20:44 |
| J1m | WebMaven, just a little bit. | 20:44 |
| WebMaven | OK. | 20:44 |
| WebMaven | premise: arguably, the most important factor in the *early* growth of the wen was the ability to 'view-source' and copy/modify/republish to your own server. | 20:45 |
| WebMaven | what would it take to get that same cycle happening for Zope3 apps? Can we get automatically publish the ZCML for copying? | 20:45 |
| WebMaven | (optionally, of course) | 20:46 |
| WebMaven | Umm... "early growth of the web" | 20:47 |
| J1m | I don't accept that premise. | 20:48 |
| WebMaven | Ok... | 20:49 |
| J1m | It certainly wasn't true for dynamic (e.g. cgi) apps. | 20:49 |
| WebMaven | early being 1993 1994. | 20:49 |
| J1m | The "source" of a Zope application is the entire application, with .pt files, .py files, etc. | 20:49 |
| WebMaven | Well, yes. | 20:51 |
| *** _agroszer has joined #zope3-dev | 20:51 | |
| *** agroszer has quit IRC | 20:52 | |
| WebMaven | But integrating that with the rest of a site (ie, I want to add a cool app to my zope 3 site) can be non-obvious. | 20:52 |
| WebMaven | It's easy to add a 'download this' footer to an app, but that won't include site-specific customizations. | 20:52 |
| WebMaven | Can we make those as easy to distribute? | 20:53 |
| J1m | ah cool, I can reproduce 465 on 3.1. | 20:54 |
| J1m | So I guess someone fixed it. :) | 20:54 |
| J1m | WebMaven, I don't see how. | 20:55 |
| WebMaven | :-( | 20:55 |
| J1m | I'm also not very motivated to try to figure out how to. | 20:55 |
| WebMaven | OK. | 20:55 |
| WebMaven | I'll think about it some more. | 20:56 |
| projekt01 | J1m, just a quick question. Do you have plan to do add TTW development to the core or do you think this is a job for the Z3ECM project | 20:57 |
| J1m | SteveA, any progress on http://www.zope.org/Collectors/Zope3-dev/446? | 20:58 |
| J1m | projekt01, well, depending on what we decide the "core" is, I think it should be in the core. Or, more precicely, I don't see it as being content-management specific, although there could certainly be CM-specific TTW facilities. | 20:59 |
| d2m | WebMaven: could you provide me any info on 'Gamma' ? | 20:59 |
| projekt01 | J1m, Ok, I see | 21:00 |
| mgedmin | J1m, do you have an opinion about http://www.zope.org/Collectors/Zope3-dev/497 ? | 21:00 |
| J1m | mgedmin, seems reasonable to me. | 21:01 |
| mgedmin | great, then I'll go ahead with the change | 21:01 |
| J1m | I'm gonna start agitating for a beta release. | 21:02 |
| projekt01 | mgedmin, perhaps you get problems with the logout concept if you include local principals. | 21:03 |
| mgedmin | projekt01, ? | 21:04 |
| projekt01 | As far as I know there is a logout problem with global defined principals. | 21:04 |
| WebMaven | d2m: Not yet. | 21:04 |
| mgedmin | projekt01, what does that have to do with me? | 21:04 |
| d2m | WebMaven: if, could you contact me at michael@d2m.at ? | 21:04 |
| WebMaven | d2m: It *will* be released before PyCOn. | 21:04 |
| projekt01 | mgedmin, if you include the check for local principals perhaps the logout problem happens also to them. | 21:06 |
| mgedmin | what check? what local principals? what logout problem? | 21:06 |
| WebMaven | d2m: If you have questions about support for specific use-cases, I may be able to answer privately. | 21:06 |
| mgedmin | I have no idea what you're talking about, sorry | 21:06 |
| projekt01 | perhaps I missunderstand the issue 447 | 21:07 |
| mgedmin | I said 497 | 21:07 |
| projekt01 | ok, so I'm totaly wrong ;-) | 21:07 |
| J1m | mgedmin, speak more clearly. ;) | 21:07 |
| mgedmin | which is about HTTP DELETE requests returning 405 Method Not Allowed when the parent of an object isn't adaptable to IWriteDirectory | 21:07 |
| mgedmin | yeah, I often mumble :-/ | 21:07 |
| * mgedmin grins | 21:08 | |
| projekt01 | ;-) | 21:08 |
| *** _agroszer has quit IRC | 21:09 | |
| *** MiUlEr has joined #zope3-dev | 21:32 | |
| *** J1m has quit IRC | 21:36 | |
| *** MrTopf has quit IRC | 22:22 | |
| *** zmi_junkie has joined #zope3-dev | 22:33 | |
| *** mgedmin has quit IRC | 22:33 | |
| *** MiUlEr has quit IRC | 22:55 | |
| *** zmi_junkie_ has joined #zope3-dev | 23:06 | |
| *** zmi_junkie has quit IRC | 23:12 | |
| *** dobee has quit IRC | 23:20 | |
| *** romanofski has quit IRC | 23:32 | |
| *** projekt01 has quit IRC | 23:33 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!