IRC log of #zope3-dev for Sunday, 2005-12-04

*** hazmat_ has joined #zope3-dev00:27
JoaoJoaohow do I programatically create a new sqlos object inside a container00:36
*** zagy has joined #zope3-dev00:52
*** zagy has quit IRC01:00
JoaoJoaohow do I commit my changes in Z3?01:04
JoaoJoao(the transaction)01:04
*** yota has quit IRC01:08
*** projekt01 has joined #zope3-dev01:09
benjiJoaoJoao, I have to go, but if memory serves, just do "import transaction" and then "transaction.commit()"01:15
*** benji has quit IRC01:15
projekt01srichter, ayt?01:34
*** sashav has quit IRC01:50
projekt01srichter, there is a bug in XMLRPC and apidoc02:02
*** MiUlEr has joined #zope3-dev02:13
JoaoJoaoif I want to add an object to a container is object['newobjid'] = mycontainerobj the only way?02:13
projekt01container.__setitem__('name', obj)02:13
projekt01which is called if you use: container['name'] = obj02:14
JoaoJoaoprojekt01: okay, it's just that sqlos doesn't care about the id I give, it renames it02:16
projekt01Perhaps there is a name chooser involved?02:16
JoaoJoaoprojekt01: maybe I can just set the name in the afterAdd event02:17
JoaoJoao'afterAdd' -> objectaddedevent02:17
projekt01Do you have already a object with the same name in the container?02:17
JoaoJoaoprojekt01: No, but it gives the objects names like 'sqlquezt.Pergunta.4'02:18
projekt01the name is not ignored normaly, except the container have it's own name  chooser where chooses or changes the given name02:19
JoaoJoaothat's the case in sqlos I believe02:19
JoaoJoaohow could I override the name chooser?02:20
projekt01I 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
projekt01Did you implement a own container?02:21
projekt01Or is it a part of sqlos?02:22
JoaoJoaoI implemented my own containers02:22
projekt01can you paste the class code and the configure.zcml?02:23
projekt01can you paste the code of: SQLObjectContainer02:30
projekt01and perhaps the interface of this class?02:30
JoaoJoaothe class:
projekt01There is a name chooser: SQLObjectNameChooser02:32
JoaoJoaoahhh now I see it02:32
*** Volpe has quit IRC02:32
projekt01did you understand it?02:32
projekt01I guess the namechooser will get a utility with the given name.02:33
JoaoJoaoit gets the factory name and puts ".<id>"02:33
projekt01I guess this is for the DB connection or something like that02:33
JoaoJoaoto avoid name conflicts02:33
projekt01I guess, but I'm not sure. The name is used as the registered utility name02:33
projekt01So there has to be a utility for each name02:34
projekt01See: factory = zapi.getUtility(IISQLObject, name, context=self.context)02:34
projekt01As far as I can see there is a named IISQLObject utility02:35
projekt01is this correct, you like to store IISQLObjects in this container?02:35
JoaoJoaoyes, I have a specific folder for my package, and in the ObjectAddedEvent I add a container for each sqlobject type02:37
projekt01Ok, that's to specific for me, I don't know sqlos.02:39
projekt01I hope I could point you to the right direction.02:39
JoaoJoaoprojekt01: Can I change the name chooser for my object?02:40
projekt01Yes, you can do this. Register a own name chooser to a more specific interface form your container.02:40
projekt01I guess this whould be: IQuestionarioContainer02:41
projekt01But make sure that you understand the part in SQLObjectNameChooser02:42
projekt01I don't really know what's happen there excatly02:42
projekt01Perhaps there are doctests where will give you a overview02:43
JoaoJoaoit seems that sqlos requires the name to be that way, so02:55
*** Theuni has joined #zope3-dev02:57
*** romanofski is now known as rom|ZZZ03:03
*** Theuni has quit IRC03:17
*** MiUlEr has quit IRC03:20
JoaoJoaoI'm trying to add an object to the container after a submit in a view:
JoaoJoaobut it's not doing anything03:38
projekt01try to use: self.request.get('acao', None)03:48
projekt01what's that? def __init__(self,context,request,base_url=''):03:48
projekt01is this a BrowserView class?03:48
projekt01where did you get the base_url? I guess this isn't used.03:49
JoaoJoaothis is a BrowserView, yes03:49
JoaoJoaoJust removed the base_url :P03:49
*** andres_ has joined #zope3-dev03:50
projekt01Ok, are you sure you you get the 'acao' value?03:50
projekt01from the request?03:50
*** andres has quit IRC03:50
JoaoJoaoyes, I made it raise an Exception at the end of the if statement03:50
projekt01And you like to store a Questionario03:52
JoaoJoaoin the 'questionarios' container03:52
projekt01in a container called 'new' where is contained in the container where your view is shown?03:52
JoaoJoaonew is supposed to be the new object name03:53
projekt01Ah, I see the container is called 'questionaries' and the object is called 'new'03:53
projekt01Is there a container 'questionaries' already in your container?03:53
JoaoJoaoyes, it's always created in my SQLQueztContainer (in the ObjectAddedEvent)03:55
projekt01I don't see what's wrong, this should work as far as I see.03:55
projekt01No traceback?03:56
projekt01No error?03:56
JoaoJoaoNo errors03:56
JoaoJoaodamn, there was a wrong import in my view04:00
JoaoJoaonow it works like a charm04:01
JoaoJoaoI just wished sqlos didn't make me use <factory>.<id> names04:01
JoaoJoaonow I'll need to make some Ajaxy stuff04:03
projekt01JoaoJoao, why not Ajaj04:12
JoaoJoaoAjaj, much better in fact04:16
JoaoJoaonow I just need to understand this resources thing04:16
projekt01Did you know about the jsonserver implementation form Jim Washington?04:19
JoaoJoaoyes, I've even been using as the JSON-RPC server for a Palm/PocketPC sync application04:20
projekt01srichter, ayt?04:21
projekt01Are you interested in a different json javascript library then jsolait?04:22
JoaoJoaoI thought about Mochikit04:23
projekt01Ok, tell me if this will work for you.04:24
projekt01I added a base library for handle json via a xmlhttp request. But there is no other Ajax stuff implemented.04:25
projekt01depends on: svn://
JoaoJoaoI'll take a look, thanks04:27
projekt01Ok. let me know if you use it or if you have questions.04:28
JoaoJoaoprojekt01: What is the equivalent to "javascript_slot" in Z3?04:33
* JoaoJoao lost in this resource think04:45
projekt01There is a viewlet concept imlemented in zope.viewlet where is used in the Boston skin. Try http://localhost:8080/++skin++Boston04:48
newpershi projekt0104:49
projekt01hi, newpers04:49
*** natea has quit IRC05:03
JoaoJoaoprojekt01: I need to register the whole mochikit directory05:04
projekt01I have no idea, that was the reason why I wrote a own library.05:05
JoaoJoaoI tried resourceDirectory05:05
projekt01Yes, that is the starting point.05:06
JoaoJoaoand then e.g. /@@/mochikit/lib/Mochikit/Mochikit.js05:06
JoaoJoaoI registered the directory for the "default" layer05:06
*** hazmat_ has quit IRC05:20
projekt01JoaoJoao, that should work05:22
*** projekt01 has quit IRC05:24
JoaoJoaoah resourceDirectory doesn't support subdirectories05:39
JoaoJoaothis is terrible05:40
*** JoaoJoao has quit IRC05:43
*** stub has joined #zope3-dev06:16
*** stub has quit IRC07:04
*** natea has joined #zope3-dev07:13
*** stub has joined #zope3-dev07:48
*** natea_ has joined #zope3-dev08:56
*** natea has quit IRC09:07
*** natea_ has quit IRC09:50
*** rom|ZZZ is now known as romanofski10:34
*** Theuni has joined #zope3-dev10:45
*** d2m has joined #zope3-dev10:54
*** sashav has joined #zope3-dev11:13
*** _agroszer has joined #zope3-dev11:21
*** Theuni has quit IRC11:35
*** natea has joined #zope3-dev11:37
*** dobee has joined #zope3-dev11:46
*** natea is now known as natea|zZz12:02
*** BjornT_ has quit IRC14:30
*** BjornT has joined #zope3-dev14:31
*** mgedmin has joined #zope3-dev14:53
*** yota has joined #zope3-dev14:56
*** sashav has quit IRC15:08
*** projekt01 has joined #zope3-dev15:10
projekt01srichter, ayt?15:11
*** sashav has joined #zope3-dev15:15
*** BjornT has quit IRC15:19
*** BjornT has joined #zope3-dev15:19
*** sashav has quit IRC15:25
*** BjornT has quit IRC15:27
*** BjornT has joined #zope3-dev15:27
*** _agroszer has quit IRC15:42
*** _agroszer has joined #zope3-dev16:21
*** andres_ has quit IRC16:37
*** Jasper has joined #zope3-dev16:42
*** Jasper has quit IRC16:57
*** sashav has joined #zope3-dev17:17
*** MacYET__ has joined #zope3-dev17:19
*** J1m has joined #zope3-dev17:27
*** bradallen has joined #zope3-dev17:28
*** philiKON has joined #zope3-dev17:37
*** _agroszer is now known as agroszer17:37
*** sashav_ has joined #zope3-dev17:42
*** sashav has quit IRC17:42
*** sashav_ is now known as sashav17:42
*** sashav has quit IRC17:45
*** sashav has joined #zope3-dev17:59
*** MrTopf has joined #zope3-dev18:05
J1mAnybody wanna argue about layers? ;)18:11
*** sashav has quit IRC18:15
*** MJ has quit IRC18:18
MacYET__in which context?18:19
J1mzope 3 :)18:19
MacYET__sorry, i don't get it :)18:20
J1mIN particular, the notion of "default layer" seems rather confused.18:20
J1mThen you don't have to argue about it. :)18:20
MacYET__sorry, i read  'lawyer'18:21
philiKONJ1m, hey18:21
philiKONi found the default layer a bit annoying too18:22
philiKONwhen i ported five to zope 3.218:22
J1mAny idea wtf default layers are supposed to be about?18:22
J1mFortunately, they don't seem to "work", for some definition of "work".18:23
philiKONfor example?18:23
J1mThe 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
J1mBut the implementation of this is totally broken.18:24
J1mand 444 complains about this.18:24
philiKONdunno the bugs actually18:25
philiKONbut i think it's not needed really18:25
philiKONthe browser:defaultLayer directive18:25
J1mwell, it just doesn't work.18:25
philiKONwell, i think i know why18:25
philiKONbecause the directive handlers default to   layer=IDefaultLayer18:25
philiKONit's as simple as that18:25
J1mThe implementation is broken for at least 2 reasons.18:25
philiKONi really think we could get rid of IDefautLayer18:25
philiKONmake it IBrowserRequest18:25
J1mOK 3 reasons. ;)18:26
J1mThe default layer *is* basically the type.18:26
J1mSince that is the usuall fallback.18:26
J1mIt's a mess.18:27
philiKONdon't know what you mean by the default layer is the type...18:27
J1mwell, it depends on the code you are looking at.18:27
J1mThe code in falls back to presentation type.18:27
J1m(basically a request type)18:27
J1mThe code in defines an IDefaultLayer that extends IBrowserRequest.18:28
J1mIt might as well ise IBrowserRequest.18:28
* projekt01 layers are very useful but I agree on simplify this part.18:28
J1mI suppose there is a proposal somewhere ...18:29
philiKONJ1m, let's get rid of IDefaultLayer, make IBrowserRequest the default18:29
philiKONand get rid of browser:defaultLayer18:29
philiKONsince it doesn't work anyway18:29
J1mThat's what I'm leaning toward.18:29
J1mBut probably for 3.2.18:29
J1mI mean 3.418:30
* philiKON hopes you mean 3.318:30
J1mI'm inclined to mark the "feature" permanently broken.18:30
J1mAnd deprecate the directive.18:30
projekt01J1m, you mean only browser:defaultLayer and not the layers at all?18:30
J1mwhich means we can't actually remove it until 3.4.18:30
philiKONright, right18:31
J1mprojekt01, no, layers are fine.18:31
projekt01Ok, I agree on this18:31
J1mJust the broken default layer concept.18:31
philiKONJ1m, 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 concept18:32
philiKONas separate concepts i mean18:33
J1mperhaps we don't.18:33
projekt01philiKON, 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
philiKONprojekt01, right, nothing would change there18:34
philiKONexcept that everythiing would be skins18:34
projekt01This allows you to develop a package including a layer where others can use in their skin18:34
philiKONlayers and skins would all be skins18:34
philiKONskins could extend IInterface or other skins18:34
projekt01Then you have to inherit from this skin18:34
projekt01Ah, Ok18:34
philiKONerr, skins could extend Interface or other skins18:34
* philiKON proposes to consolidate layers + skins into one concept18:36
projekt01Ok, 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
projekt01philiKON, +118:36
philiKONnot sure what you mean by that sentence18:37
projekt01We have to offer a (layer) where we can register views and make sure that somebody can use this (layer) in his custom skin18:38
projekt01That's the target of the layer - skin concept, separate the registration (layer) and the (implementation) skins18:40
projekt01Or not?18:40
philiKONnot really18:40
philiKONat least not for me18:40
philiKONthe idea of layers is that you can override views from a "lower" layer18:40
philiKONlet's take this example:18:41
philiKONi want to override the @@contents.html view18:41
philiKONfor my skin18:41
philiKONsomebody who deploys a site is looking to customize the default skin18:41
philiKONso, right now he has to make a new layer18:41
philiKONregister the @@contents.html view for that layer18:41
philiKONand then make a skin18:41
philiKONcomposed of the default layer, the layer of the default skin (e.g. 'rotterdam') and then his own custom layer18:42
philiKONthat's a lot of clutter18:42
philiKONwhat if you'd only have to make a new skin from the skin you're trying to customize18:43
philiKONand you can register your views for that skin directly18:43
philiKONthat's what i'm msotly looking at18:43
projekt01Yes, 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
philiKONi'm not sure if i understand that18:45
philiKONwhat are you offering in these layers that couldn't be "offered" in the 'default' layer?18:46
*** J1m has quit IRC18:46
philiKONand what's a skin "implementation"?18:46
*** MacYET__ has left #zope3-dev18:46
projekt01I 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, etc18:46
projekt01But perhaps this could be done in your simplification as well.18:47
philiKONyeah, my simplification just merges the concepts18:48
projekt01Right now we use a minimal layer or a trusted layer. There are no images or javascript registered, only traverser or important views18:48
philiKONit doesn't keep you form separating stuff in different skin interfaces18:48
philiKONah, ok18:49
projekt01I see18:49
philiKONso, make that a skin as well18:49
projekt01Yes, I see, we don't need a layer or skin implementation for this separation.18:49
philiKONcanb e covered by just one concept18:51
projekt01Ok, I agree18:51
* projekt01 is going to dinner18:51
andrew_msimple question: how do i link from a pagetemplate to /blah.html in a way that works with virtual hosts?18:51
projekt01see you18:52
*** projekt01 is now known as _projekt0118:52
andrew_mlike <a href="???/blah.html">...</a>18:53
andrew_mi'm messing with @@, ++, .. but no joy18:54
philiKONandrew_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.html18:56
andrew_mi'm basically trying to switch from http://myserver:8080 to http://myserver/something/ with apache virtual hosts18:58
*** ignas has joined #zope3-dev18:58
philiKONand why doesn't simply linking to /blah.html not work?18:59
andrew_mit links to /blah.html instead of /something/blah.html18:59
philiKONwell, 'something' isn't your virtualhost root18:59
mgedminphiliKON, imagine an apache RewriteRule /something/(.*) http://localhost:8080/$1 [R]19:00
andrew_mmgedmin: yeah, thanks19:00
philiKONuh, ok19:00
andrew_mmaybe i'm trying the impossible here :/19:00
mgedminandrew_m, does your view have a reference to the root folder?19:01
philiKONno, i think it's quite possible19:01
mgedminin that case tal:attributes="href ${view/root/@@absolute_url}/blah.html" ought to work19:01
philiKONandrew_m, you just don't have to put things inside a 'something' folder on the zodb side19:01
philiKONmgedmin, view/root ???19:01
andrew_mphiliKON: yes, i don't19:01
mgedminthe view would have to set a 'root' attribute19:01
philiKON${root/@@absolute_url} i think19:01
philiKONroot is a zpt variable19:02
mgedminis there a 'root' in the default TALES namespace?19:02
mgedminI didn't know that19:02
philiKONi bet IVirtualHostRequest also defines a method that gives you similar info]19:03
andrew_m<a tal:attributes="href ${root/@@home.html}">Back to Home.</a>19:03
philiKONno no no19:03
andrew_mPTRuntimeError: ['Compilation failed', 'zope.tal.taldefs.TALError: Invalid variable name "@@home.html}"19:03
*** stub has quit IRC19:04
*** sashav has joined #zope3-dev19:04
andrew_mhmm: PTRuntimeError: ['Compilation failed', 'zope.tal.taldefs.TALError: Invalid variable name "@@home.html" in expression u\'${root/@@absolute_url}/@@home.html19:05
mgedminaargh, "string:${root/@@absolute_url}/@@home.html" :-)19:06
andrew_mKeyError: 'root' :)19:06
philiKONgotta reboot19:08
*** philiKON has quit IRC19:08
andrew_mah: string:${context/@@absolute_url}/@@home.html might be working..19:09
andrew_mor maybe that's not the same.. hmm19:09
*** J1m has joined #zope3-dev19:12
*** natea|zZz is now known as natea|sanfran19:13
mgedminit might not be the same19:16
mgedminandrew_m, what is the context of your view?19:16
andrew_mmgedmin: any folder19:16
andrew_mi guess.. it's the logout page19:16
mgedminin that case you may add a function to your view class19:16
mgedmindef root(self): return zapi.getRoot(self.context)19:17
mgedminand then use19:17
mgedminaargh, "string:${view/root/@@absolute_url}/@@home.html" :-)19:17
andrew_mok, i'll try that thanks19:17
mgedmin(the aargh bit is optional :)19:17
J1mmgedmin, do you know how virtual hosting works?19:18
J1mOr where it is documented?19:18
andrew_mJ1m: there's something in srichter's book, but more about configuration19:18
mgedminJ1m, I do19:19
J1mI'm trying to look at
J1mBut I don't have a firm grasp of how virtual hosting is used.19:20
*** philiKON has joined #zope3-dev19:20
* J1m looks at staphans on-line book19:21
* mgedmin looks19:21
*** _projekt01 is now known as projekt0119:21
* projekt01 virtualhosts work very well for me19:22
projekt01I udpated most parts of z3 for vh support e.g. xmltree, breadcrumbs etc.19:23
projekt01And I use vh in production.19:23
J1mI wish there was a document that specified the syntax of a ++vh thing.19:24
andrew_mprojekt01: hmm.. so how would you link to a simple URL like /home.html when using virtual hosts?19:25
projekt01Issue 465 describes things like "Page "above" site root level doesn't exist19:25
andrew_mprojekt01: from a page template that is19:25
philiKONJ1m, there is... otherwise i couldn't have figured it out for my book ;)19:25
J1mphiliKON, I dunno, you might have read the code. :)19:25
projekt01andrew_m, you have to write it by yourself.19:26
mgedminexcept that the second '++' traversal element is required19:27
mgedminnot optional, like it was in the initial proposal19:27
projekt01andrew_m, what url do you mean?19:27
J1mso 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
andrew_mprojekt01: just any absolute URL, e.g. /home.html, a view for the root folder19:28
J1mI guess this gives me enough to try and reproduce the bug.19:28
* mgedmin tries to reproduce
projekt01andrew_m, Use the normal absolute URL19:28
* J1m says "Yay!" :)19:29
projekt01andrew_m, do you try to test it without a real virtual host (apache) setup?19:29
mgedminhm... skins and ++vh++ do not like each other19:29
mgedminhttp://localhost:8080/++skin++Boston/++vh++http:localhost:8080/++/zz shows me the 404 page, but not skinned properly19:30
mgedminhttp://localhost:8080/++skin++Boston/++vh++http:localhost:8080/++skin++Boston/++/zz shows the skinned 404 page19:30
andrew_mprojekt01: yes, well it should work with and without vh's19:30
mgedminit appears that ++vh++ doesn't automatically include the skin in the generated URLs19:31
mgedminbut this is a different problem from 46519:31
projekt01mgedmin, Does this work: http://localhost:8080/++skin++Boston/zz19:31
andrew_mprojekt01: <a href="/home.html">Home</a> will link to /home.html and not <virtual host>/home.html19:31
mgedminprojekt01, it does19:31
projekt01J1m, mgedmin, we use it in production. It works with apache. See you can ensure that this is a z3 app with
mgedminI managed to reproduce the bug19:33
mgedminhttp://localhost:8080/++skin++Boston/plugh/++vh++http:localhost:8080/++skin++Boston/++/zz gives me the proper 404 message19:33
mgedminhttp://localhost:8080/++skin++Boston/plugh/++vh++http:localhost:8080/++/zz gives me a SystemError19:33
mgedminI had to make 'plugh' a site19:33
mgedminwhen 'plugh' was a regular folder, both URLs gave me 404 errors (but one wasn't skinned properly)19:33
mgedminwait a second, I'm wrong19:35
projekt01btw, this will work for me: http://localhost:8080/++skin++MySkin/somefolder/
mgedminI'm wrong; I cannot reproduce the error -- I had accidentally omitted the /++/ thus causing an error in the ++vh++ handler19:36
projekt01andrew_m, sure, /home.html is a absolute url path19:36
andrew_mprojekt01: yes, that's what i am trying to solve :)19:37
andrew_mprojekt01: i expect a solution with ${something} and probably some @@ and some ++ somewhere19:37
J1mmgedmin, I can't reproduce this error either.19:38
projekt01andrew_m, use "./home.html" as a relative path.19:38
J1mOf course, there's the error you pointed out that the skin is lost.19:38
J1mIn fact, the default skin is lost too.19:38
andrew_mprojekt01: no good... the link can appear in some sub folder like /blah/blah/blah.html19:38
projekt01andrew_m, what's the base url for home.html?19:39
mgedminI do not understand the bit about the default skin being lost19:39
andrew_mprojekt01: just /home.html (in the root (without vh's))19:39
projekt01andrew_m, register a virtualhost_url instead of a absolute_url which points to the virtual host root instead to the application root.19:40
J1mvirtual hosting is mostly not working for me.19:41
projekt01Btw, virtualhost urls get rewriten by Apache's RewriteRule directive!19:41
mgedminJ1m, in what way?19:42
projekt01RewriteRule (/?.*) http://localhost:8080/++skin++Admin/vhosts/extranet/++vh++http:admin.amadeus.demo:80/++$1 [P,L]19:42
mgedminvirtual hosting works, but too complicated19:42
J1mMy understanding is that generated URLs should be virual.19:42
J1mWhen I go to:19:42
J1min a fresh zope19:42
projekt01Then you have problems with the HTTP server bindings since we use Twisted!19:43
* mgedmin does that19:43
J1mThe links to menu items and folder items are not virtual.19:43
mgedminthat's because they are relative links19:44
mgedminand your browser sees the ++vh++ bit19:44
mgedminand there is no <base href="..." /> tag19:44
J1mI guess that use of ++vh++ needs to trigger that.19:44
mgedminif you View Document Source, you won't find '++vh++' inside19:45
J1mwe need to generate a base href any time the logical url doesn't match the fiven url.19:45
projekt01Sorry, localhost and works but the original IP of your computer won't19:45
* mgedmin is completely not familiar with base href generation logic in Z319:45
J1mmgedmin, what I just said is the guiding principle.19:46
*** tiredbones has quit IRC19:47
J1mBut the virtual hosting code doesn't seem to know about this.19:47
J1mto see this, add a couple of items to the root folder and then go to:19:48
J1mIn the second case, the logical and actual URLs match, so no base href.19:48
J1mIn the former case, they don't, o Zope generates a base href.19:49
mgedminwhere in Z3 is the <base href> code?19:49
J1msearch for base_needed19:51
mgedminshould the presence of ++vh++ always imply base_needed = True?19:52
projekt01J1m, I'm confusing. Are you suggesting that virtual host should generate ++vh++ url's?19:52
projekt01This is the job of Apache!!!19:52
J1mmgedmin, unfortunately, the plumbing isn't clear.19:53
J1mprojekt01, no, just the opposite.19:53
J1mprojekt01, the urls generated by Zope need to omit the ++vh++ bit.19:53
mgedminJ1m, easy to do: if self.getVirtualRoot() is not None: base_needed = True19:53
J1mIn fact, the URLs generated by zope shoudl refelect the virtual URL.19:54
J1mmgedmin, ah, cool19:54
*** natea|sanfran has quit IRC19:54
mgedminsee also src/zope/app/traversing/ftests/test_vhosting.py19:54
mgedminthere are some functional tests that look at <base> when ++vh++ is used19:54
projekt01J1m, Ok19:55
J1mmgedmin, right, but they don't test that a base is triggered by vh.19:57
J1mBut I suppose it would be easy to extend them to do so.19:57
projekt01I don't understand why the use of ++vh++ needs a base and no virtual host not?19:57
J1mprojekt01, did you try the examples I gave?19:58
J1mThe problem is that virtual hosting needs to affect relative URLs too.19:58
J1mThe only way they can do this is via base href.19:59
*** BjornT has quit IRC19:59
J1mmgedmin, I guess I'll try to update this test to make sure that base href gets triggered.19:59
J1mand then make it pass.20:00
projekt01J1m, Where do you think will a relative url like "./home.html" end if the virtual host url points to without a base url?20:01
J1mprojekt01, did you try the examples I gave?20:01
projekt01You mean this: http://localhost:8080/++vh++http:
J1mbefore doing that, add some items to the root folder20:02
J1mThen look at the links to these items with and without the trailing slash.20:03
*** BjornT has joined #zope3-dev20:05
projekt01I don't see any difference. What should be different? My links are both time the same like: ><A href="demos">demos</A>20:07
J1mLook at the links your browser shows in the status bar.20:07
projekt01where does this came form?20:09
projekt01is this a request header information?20:09
*** natea has joined #zope3-dev20:09
J1mah wait20:10
J1mI'm being slightly stupid.20:10
J1mThis is an unrealistic test.20:10
J1mIf you have apache in front of Zope, then the browser will submit virtual urls in the first place.20:10
J1mso this is not a problem.20:11
projekt01Yes, yes20:11
projekt01that's what I mean20:11
J1mIt is only an apparent problem when tsting virtual hosting directly.20:11
J1mOK, then we can drop this.20:11
mgedminwell, perhaps it would help developers that try to debug other virtual hosting issues20:12
J1mSo, now we just have the skin mangling to contend with.20:12
mgedminI think this is not the first time someone saw a ++vh++ in the browser's status bar and assumed virtualhosting didn't work20:12
J1mmgedmin, I dunno.20:12
J1mBut generating base hrefs is generally frowned upon.20:13
projekt01but 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
J1mwe don't want to generate them unless we absolutely need to.20:13
projekt01J1m, I agree20:13
mgedminprojekt01, we were talking about, not andrew's use case20:14
mgedminI think20:14
J1mso wrt that, I can't reproduce that behaviour, but20:14
J1mI;m seeing rather broken skin behavior.20:14
*** tiredbones has joined #zope3-dev20:15
mgedminit is the interaction of shiftNameToApplication and setVirtualHostRoot20:16
mgedminshiftNameToApplication modifies self._app_names20:16
mgedminsetVirtualHostRoot overwrites self._app_names20: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-dev20:17
andrew_mprojekt01: would be cool.. i need that in lots of places.. guess i have to write a function behind every view for now20:17
mgedminandrew_m, but do you want the URL of the root folder, or the URL of the site?20:18
andrew_mmgedmin: i didn't have the nerves to even think about sites yet (i guess i'm just using the default site (?))20:19
mgedminthe root folder is a site20:19
andrew_mthat's the only site i have then20:19
mgedminbut you can make subfolders sites too20:19
mgedminis there a way to access the current site from ZPT?20:19
mgedminzapi:site or ++site++ or whatnot?20:20
projekt01mgedmin, as far as I know can only Isite used for virtual host roots. right?20:20
mgedminprojekt01, I did not understand what you said20:20
projekt01you can only point to a ISite as a virtual host root.20:21
projekt01not a folder20:21
mgedminyou can point to anything as a vhost root20:21
projekt01are you sure?20:21
mgedminbut you will need an additional rule for /@@/ to handle resources if you do so20:21
mgedminI use that in production20:21
projekt01mgedmin, good idea!20:22
J1mmgedmin, are you seeing the skin display messed up?20:23
J1mOr are you seeing the skin not reflected in the URLs?20:23
J1mHm, I'm probably confused.20:24
projekt01J1m, I guess it depends if you put the ++skin++ in front of ++vh++ or at the end in your url20:25
projekt01both is possible20:25
projekt01tha part in fornt of ++vh++ get hidden called and the part after ++vh++ get included in the real url20:26
mgedminJ1m, if I go to http://localhost:8080/++skin++Boston/++vh++http:
mgedminI get a page that refers to
mgedminwhile it should refer to
J1mI don't agree.20:27
*** philiKON has quit IRC20:28
projekt01mgedmin, the skin.css is served from the Boston skin20:28
J1mIn this example, the ++skin++ is in the physical part pf the URL that is overwritten by the virtual part.20:28
J1mPresumably, it was provided by the apache rewrite rule.20:28
J1mso it shoudln't be included in virtual URLs, IMO.20:29
J1mHowever, when I go to that URL, the skin is messed up.20:29
J1mI'm guessing that if I has apache in front, I'd be OK though.20:30
J1mBecause, as it standsm it can't find the css.20:30
J1mWhich is, I suspect, what projekt01 was just saying. :)20:30
J1mI suspect I shoudln't be fooling with this without something in front rewriting things.20:31
projekt01J1m, Yes, because you don't have a apache and DNS setup where is able to deliver the link
J1m(dns wouldn't be a problem :)20:31
projekt01Ok, but the missing RewriteRule inApache20:32
mgedminperhaps you are right20:32
projekt01Note: virtual hosts are only usable with a virtual server20:32
J1mGiven how confuded I am, I wouldn't count on it. ;)20:32
mgedminno, wait20:32
mgedminif I go directly to http://localhost:8080/++skin++Boston/20:33
J1m"confuded" sounds like a real word, sort of. ;)20:33
mgedminthen the HTML source explicitly refers to http://localhost:8080/++skin++Boston/@@/toolbar.css20:33
mgedminas an absolute URL20: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 URLs20:34
J1mBut suppose the user types in:20:34
projekt01mgedmin, there is no wrong output in the browser bar. This happens only because there is no Apache where delivers your real call.20:35
J1mto explcitly select a skin.20:35
J1mwhere is virtual.20:35
J1mThe app sees:20:35
J1mHere the skin is part of the virtual url and should be included in generated urls.20:37
mgedminapparently ++skin++ must be the very first name (BrowserRequest.shiftNameToApplication requires this), so users effectively can't use ++skin++ in virtual URLs20:37
mgedminyou can't even do http://localhost:8080/++debug++errors/++skin++Boston/20:37
mgedminor http://localhost:8080/++debug++source/++skin++Boston/20:37
mgedminI mislike that20:37
projekt01J1m, if you like to hide the skin you can use:20:38
J1mworks for me20:38
J1mprojekt01, yes, I know.20:38
J1mI was giving a different use case.20:38
projekt01And the following will only work if the apache get setup correct:20:39
mgedminJ1m, it works -- but only if your RewriteRule points to the root folder20:39
mgedminnever mind, it works in other cases as well20:40
mgedminI was mistaken20:40
J1mworks for me too.20:40
J1mTo be clear, there are 2 use cases:20:40
projekt01J1m, but only if you have a item called 'aaa' in the root20:40
mgedminwell, duh20:41
mgedminand also only when you have Zope 3 running on localhost port 808020:41
J1m1. 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 nods20:42
*** BjornT has quit IRC20:42
*** BjornT has joined #zope3-dev20:42
J1m2. 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
J1mso, I don't think we have a problem.20:42
WebMavenJ1m: do you have any time for a bit of blue-sky Q&A?20:43
J1mIn addition, I can't reproduce 465, so I think I'll mark that as non-reproduceable.20:43
J1mso I think we're ready for a beta!20:44
J1mWebMaven, just a little bit.20:44
WebMavenpremise: 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
WebMavenwhat 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
WebMavenUmm... "early growth of the web"20:47
J1mI don't accept that premise.20:48
J1mIt certainly wasn't true for dynamic (e.g. cgi) apps.20:49
WebMavenearly being 1993 1994.20:49
J1mThe "source" of a Zope application is the entire application, with .pt files, .py files, etc.20:49
WebMavenWell, yes.20:51
*** _agroszer has joined #zope3-dev20:51
*** agroszer has quit IRC20:52
WebMavenBut 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
WebMavenIt's easy to add a 'download this' footer to an app, but that won't include site-specific customizations.20:52
WebMavenCan we make those as easy to distribute?20:53
J1mah cool, I can reproduce 465 on 3.1.20:54
J1mSo I guess someone fixed it. :)20:54
J1mWebMaven, I don't see how.20:55
J1mI'm also not very motivated to try to figure out how to.20:55
WebMavenI'll think about it some more.20:56
projekt01J1m, 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 project20:57
J1mSteveA, any progress on
J1mprojekt01, 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
d2mWebMaven: could you provide me any info on 'Gamma' ?20:59
projekt01J1m, Ok, I see21:00
mgedminJ1m, do you have an opinion about ?21:00
J1mmgedmin, seems reasonable to me.21:01
mgedmingreat, then I'll go ahead with the change21:01
J1mI'm gonna start agitating for a beta release.21:02
projekt01mgedmin, perhaps you get problems with the logout concept if you include local principals.21:03
mgedminprojekt01, ?21:04
projekt01As far as I know there is a logout problem with global defined principals.21:04
WebMavend2m: Not yet.21:04
mgedminprojekt01, what does that have to do with me?21:04
d2mWebMaven: if, could you contact me at ?21:04
WebMavend2m: It *will* be released before PyCOn.21:04
projekt01mgedmin, if you include the check for local principals perhaps the logout problem happens also to them.21:06
mgedminwhat check? what local principals? what logout problem?21:06
WebMavend2m: If you have questions about support for specific use-cases, I may be able to answer privately.21:06
mgedminI have no idea what you're talking about, sorry21:06
projekt01perhaps I missunderstand the issue 44721:07
mgedminI said 49721:07
projekt01ok, so I'm totaly wrong ;-)21:07
J1mmgedmin, speak more clearly. ;)21:07
mgedminwhich is about HTTP DELETE requests returning 405 Method Not Allowed when the parent of an object isn't adaptable to IWriteDirectory21:07
mgedminyeah, I often mumble :-/21:07
* mgedmin grins21:08
*** _agroszer has quit IRC21:09
*** MiUlEr has joined #zope3-dev21:32
*** J1m has quit IRC21:36
*** MrTopf has quit IRC22:22
*** zmi_junkie has joined #zope3-dev22:33
*** mgedmin has quit IRC22:33
*** MiUlEr has quit IRC22:55
*** zmi_junkie_ has joined #zope3-dev23:06
*** zmi_junkie has quit IRC23:12
*** dobee has quit IRC23:20
*** romanofski has quit IRC23:32
*** projekt01 has quit IRC23:33

Generated by 2.15.1 by Marius Gedminas - find it at!