| *** stub has joined #zope3-dev | 00:04 | |
| *** jan_s has joined #zope3-dev | 00:07 | |
| *** RaFromBRC|afk is now known as RaFromBRC | 00:15 | |
| *** tvon has joined #zope3-dev | 00:48 | |
| *** jan_s_ has joined #zope3-dev | 00:52 | |
| *** bskahan has quit IRC | 00:54 | |
| *** Nicolas__ has quit IRC | 00:54 | |
| *** d2m has quit IRC | 00:57 | |
| *** jan_s has quit IRC | 01:05 | |
| *** alga has quit IRC | 01:19 | |
| *** RaFromBRC has quit IRC | 03:01 | |
| *** srichter has joined #zope3-dev | 04:07 | |
| *** ChanServ sets mode: +o srichter | 04:07 | |
| *** tvon has quit IRC | 04:33 | |
| *** SteveA has quit IRC | 04:33 | |
| *** tvon has joined #zope3-dev | 04:34 | |
| *** SteveA has joined #zope3-dev | 04:34 | |
| *** RaFromBRC has joined #zope3-dev | 04:59 | |
| *** povbot has joined #zope3-dev | 05:07 | |
| *** povbot` has quit IRC | 05:07 | |
| *** deo has quit IRC | 05:17 | |
| Damascene | i'm not sure if there are any good examples of how to use <menu and <menuItem... even if tey are defined in zcml, it isn't clear how to call them in TAL. grepping for <menu it appears that it should be something like view context/@@view_get_menu/zmi_views, but instead i'll use the menu id instead of zmi_views as the name? then "menuid/action" as the URL path? | 05:42 |
|---|---|---|
| *** WebMaven has joined #zope3-dev | 05:51 | |
| WebMaven | J1m: you still up? | 05:51 |
| Damascene | darn, i thought i had an answer to my question already haha | 05:52 |
| WebMaven | d4 7073 15 c0m1n9 | 05:53 |
| WebMaven | ph33r d4 7073 | 05:53 |
| Damascene | WebMaven: have you used the <menu commands? | 05:55 |
| WebMaven | 707e: d4 n3x7 93n3r4710n | 05:56 |
| WebMaven | nope. | 05:56 |
| *** bskahan has joined #zope3-dev | 06:23 | |
| *** Suresh-E has joined #zope3-dev | 06:25 | |
| *** jan_s_ has quit IRC | 06:37 | |
| *** bskahan has quit IRC | 07:39 | |
| *** __gotcha__ has joined #zope3-dev | 08:00 | |
| *** sashav has quit IRC | 08:14 | |
| *** __gotcha has quit IRC | 08:18 | |
| *** bskahan has joined #zope3-dev | 08:41 | |
| *** RaFromBRC has quit IRC | 08:42 | |
| zagy | moin | 09:11 |
| *** d2m has joined #zope3-dev | 09:40 | |
| *** sashav has joined #zope3-dev | 09:46 | |
| *** bskahan has quit IRC | 09:54 | |
| *** hdima has joined #zope3-dev | 10:15 | |
| *** Theuni has joined #zope3-dev | 10:34 | |
| *** `anthony has quit IRC | 10:50 | |
| *** stub has quit IRC | 10:59 | |
| *** `anthony has joined #zope3-dev | 11:03 | |
| *** MalcolmC has joined #zope3-dev | 11:03 | |
| *** jhauser has joined #zope3-dev | 11:14 | |
| *** mooded has joined #zope3-dev | 11:14 | |
| *** vlado has joined #zope3-dev | 11:29 | |
| *** [nicknam] has joined #zope3-dev | 11:47 | |
| *** jhauser has quit IRC | 11:48 | |
| *** jhauser has joined #zope3-dev | 11:49 | |
| *** `anthony has quit IRC | 12:04 | |
| *** `anthony has joined #zope3-dev | 12:16 | |
| *** J1m_ has joined #zope3-dev | 12:17 | |
| *** mgedmin has joined #zope3-dev | 12:23 | |
| *** jhauser_ has joined #zope3-dev | 12:47 | |
| *** jhauser has quit IRC | 13:04 | |
| *** stub has joined #zope3-dev | 13:05 | |
| *** jhauser_ has quit IRC | 13:09 | |
| *** jhauser has joined #zope3-dev | 13:09 | |
| *** J1m_ has quit IRC | 13:34 | |
| *** regebro has joined #zope3-dev | 14:26 | |
| regebro | Howdy! Here I am again with my pestering of Z3 internals to get Five to do a little bit more. ;) | 14:26 |
| regebro | I just looked over my code for getting menus working in Five, and I need to override almost all of the Z3 code, because of one tiny change between Zope3 and Zope2: | 14:27 |
| regebro | zope.security.management.checkPermission looks for an attribute "interaction" on zope.thread.local(), and then calls checkPermission on that. | 14:27 |
| regebro | Of course, under Zope2 there is no such attribute, so it fails, so checkPermission needs to be another checkPermission, and it ends up with basically copy/pasting all of the menu code into Five. | 14:28 |
| regebro | Kinda annoying.... Do anybody have any diea of how to NOT need to do this, but for example make the zope.thread.local() object have an interaction wvwn under Five? | 14:29 |
| SteveA | well... | 14:29 |
| SteveA | the interaction says who the logged in principal is, and what the request is | 14:30 |
| SteveA | if there is some "owned" code running, like an untrusted dtml method, then the owner of that code is also another principal in the interaction | 14:30 |
| SteveA | zope2's publisher / traverser needs to set these things in the interaction; or, the security policy needs to be changed to one that looks in the securitycontext (or whatever that is called in zope2) instead of the interaction | 14:31 |
| SteveA | the interaction in zope3 has replaced what was the "security context" in zope 2 | 14:31 |
| regebro | Hmmm. OK. There are some paths to walk down there... either have a "zope2 security policy" for Zope3, or update the publisher/traverser to behave more like Zope3s... | 14:32 |
| SteveA | the information needed by the security policy (actually, the authorization policy) should be available in zope2 anyway | 14:33 |
| SteveA | as its security context | 14:33 |
| *** srichter has quit IRC | 14:34 | |
| regebro | Sure, it's available, Zope3 just doesn't look in the correct place. ;) | 14:34 |
| SteveA | the authorization policy in zope3 is pluggable | 14:34 |
| SteveA | in my project, i'm using a totally different policy | 14:34 |
| regebro | Oh, cool, then you know where you configure that! :) | 14:35 |
| regebro | I douns the simplepolicies.py | 14:35 |
| regebro | douns/found | 14:35 |
| SteveA | or, you could write an "interaction" for zope2 that gets its information from zope2 sources | 14:35 |
| SteveA | the interaction can be set, you see | 14:35 |
| regebro | Aha, that also sounds like a good idea. Where is that set? | 14:35 |
| SteveA | it *should* be set in an event, but I think it is set in ZopePublication | 14:38 |
| SteveA | because that needs some refactoring | 14:38 |
| regebro | Ah, yeah, it makes newInteraction and endInteraction. Of course, that part is not used at all by Five, so I would need to do something similar in the Zope2 publisher. | 14:41 |
| regebro | Probably too complicated... | 14:41 |
| *** niemeyer has joined #zope3-dev | 14:42 | |
| SteveA | i suggest starting off by just replacing the authorization policy | 14:42 |
| regebro | OK. Thanks a million times, anyway, very helpful, I know where to dig now! Thanks! | 14:43 |
| SteveA | happy digging | 14:44 |
| *** niemeyer has quit IRC | 15:07 | |
| *** niemeyer has joined #zope3-dev | 15:08 | |
| *** Nicolas__ has joined #zope3-dev | 15:37 | |
| *** srichter has joined #zope3-dev | 15:38 | |
| *** adel has joined #zope3-dev | 15:42 | |
| *** ChanServ sets mode: +o srichter | 15:43 | |
| regebro | Well, replacing the authorization doesn't help, because there is still no interactions attribute on the local thread. | 15:46 |
| *** gintas has joined #zope3-dev | 15:48 | |
| SteveA | regebro: the authorization policy (sometimes called the security policy) doesn't care about interactions, afair | 15:48 |
| regebro | Possibly, but zope.security.management.checkPermission does. And it is called from loads of places. | 15:49 |
| SteveA | hmm | 15:50 |
| * SteveA -> lunch | 15:50 | |
| regebro | Hmm. THAT worked. Interesting. I wonder what side effects that will have. :P | 15:51 |
| regebro | In __bobo_traverse__ I just set zope.app.management.thread_local.interaction = getSecurityManager(). | 15:52 |
| regebro | UGLY. But it gets rid of the errors. | 15:52 |
| *** mgedmin has quit IRC | 15:58 | |
| *** Suresh-E has left #zope3-dev | 16:13 | |
| *** gintas has quit IRC | 16:16 | |
| *** stub has left #zope3-dev | 16:17 | |
| Damascene | darn, i missed mgeadmin, probably the only person who i know for a fact has used <menu zcml. ;) | 16:21 |
| regebro | What is menu zcml? | 16:23 |
| *** Nicolas__ has quit IRC | 16:30 | |
| *** __gotcha__ is now known as __gotcha | 16:47 | |
| *** srichter has quit IRC | 16:49 | |
| *** srichter has joined #zope3-dev | 16:50 | |
| *** _nicknam_ has joined #zope3-dev | 16:50 | |
| jhauser | can I do two 'for='interface...' statements into one adapter definition? | 16:51 |
| *** _nicknam_ is now known as apoirier | 16:53 | |
| srichter | jhauser: yes, but it will define a multiadapter | 16:54 |
| srichter | not an adapter that works for both interfaces | 16:54 |
| jhauser | ah ok | 16:54 |
| jhauser | and how to the later? | 16:54 |
| *** hdima has quit IRC | 16:54 | |
| *** adel is now known as adel|w | 16:56 | |
| *** [nicknam] has quit IRC | 16:59 | |
| J1m | jhauser, just use 2 adapter directives | 17:00 |
| jhauser | ok :-) thanks | 17:00 |
| jhauser | but the for="*" ist not a multiadapter definition right? | 17:00 |
| J1m | no | 17:00 |
| J1m | * means "any" interface | 17:01 |
| Damascene | regebro: it's like <menu name="mainnav"> <menuItem action="@@products.html" for="some.Int" menu="mainnav"> | 17:06 |
| Damascene | but the zcml reference is incorrect (if you put down only the 'required' ones, it's not enough to launch without errors. and no one seems to mention how to use this in TAL. | 17:06 |
| regebro | Ah, I thought you meant like a file. menu.zcml or so. ;) | 17:06 |
| regebro | Well, it should tell you what is required. Unforutnately, I haven't built any TAL menues and can't help you there. | 17:08 |
| regebro | Basically, you do globalBrowserMenuService.getMenu() to get the menu entries, but more than that I don't know. | 17:09 |
| *** zagy has quit IRC | 17:27 | |
| *** srichter has quit IRC | 17:27 | |
| *** mooded has left #zope3-dev | 17:29 | |
| Damascene | regebro: ah, okay. i'll check. i thought the browsermenuservice was going away hmm i'll recheck. | 17:43 |
| *** mkerrin has joined #zope3-dev | 17:43 | |
| regebro | Damascene, Oh, maybe it is, then I guess you get the service via getGlobaService or somesuch method. | 17:44 |
| *** tvon has quit IRC | 17:45 | |
| *** mgedmin has joined #zope3-dev | 17:51 | |
| *** mkerrin has quit IRC | 17:57 | |
| *** Nicolas__ has joined #zope3-dev | 17:59 | |
| *** bskahan has joined #zope3-dev | 18:07 | |
| *** tvon has joined #zope3-dev | 18:09 | |
| *** tav|offline is now known as tav | 18:20 | |
| *** tvon has quit IRC | 18:21 | |
| *** adel|w has quit IRC | 18:22 | |
| *** tvon has joined #zope3-dev | 18:33 | |
| *** senra has joined #zope3-dev | 18:48 | |
| *** mgedmin has quit IRC | 18:51 | |
| *** mgedmin has joined #zope3-dev | 18:51 | |
| *** vlado has quit IRC | 18:53 | |
| *** deo has joined #zope3-dev | 18:56 | |
| *** regebro has quit IRC | 19:13 | |
| *** sashav has quit IRC | 19:31 | |
| *** MalcolmC has quit IRC | 19:44 | |
| *** Nicolas__ has left #zope3-dev | 20:01 | |
| *** senra has quit IRC | 20:27 | |
| *** bskahan has quit IRC | 20:27 | |
| *** bskahan has joined #zope3-dev | 20:31 | |
| SteveA | J1m: one of my team is having problems with httpresponse.write(). I'm reading the code and I think it is doing the wrong thing. Got time to talk about it, or maybe i should mail the list? | 20:34 |
| *** zagy has joined #zope3-dev | 20:40 | |
| *** senra has joined #zope3-dev | 20:45 | |
| J1m | I can take time to talk about it. | 20:51 |
| SteveA | thanks | 20:51 |
| SteveA | response.write() just calls through to response.output(). | 20:52 |
| SteveA | output() ensures that the headers have been sent, and that the charset is set to something. | 20:53 |
| J1m | actually, write ensures that headers have been sent | 20:53 |
| SteveA | maybe I'm looking at out-of-date code then | 20:54 |
| J1m | def write(self, string): | 20:54 |
| J1m | """See IApplicationResponse | 20:54 |
| J1m | Return data as a stream | 20:54 |
| J1m | HTML data may be returned using a stream-oriented interface. | 20:54 |
| J1m | This allows the browser to display partial results while | 20:54 |
| J1m | computation of a response to proceed. | 20:54 |
| J1m | The published object should first set any output headers or | 20:54 |
| J1m | cookies on the response object and encode the string into | 20:54 |
| J1m | appropriate encoding. | 20:54 |
| J1m | Note that published objects must not generate any errors | 20:54 |
| J1m | after beginning stream-oriented output. | 20:55 |
| J1m | """ | 20:55 |
| J1m | if not self._wrote_headers: | 20:55 |
| J1m | self.outputHeaders() | 20:55 |
| J1m | self._wrote_headers = True | 20:55 |
| J1m | self._outstream.write(string) | 20:55 |
| J1m | def output(self, data): | 20:55 |
| J1m | """Output the data to the world. There are a couple of steps we have | 20:55 |
| J1m | to do: | 20:55 |
| J1m | 1. Check that there is a character encoding for the data. If not, | 20:55 |
| J1m | choose UTF-8. Note that if the charset is None, this is a sign of a | 20:55 |
| J1m | bug! The method setCharsetUsingRequest() specifically sets the | 20:55 |
| J1m | encoding to UTF-8, if none was found in the HTTP header. This | 20:55 |
| J1m | method should always be called when reading the HTTP request. | 20:55 |
| J1m | 2. Now that the encoding has been finalized, we can output the | 20:55 |
| J1m | headers. | 20:55 |
| J1m | 3. If the content type is text-based, let's encode the data and send | 20:55 |
| J1m | it also out the door. | 20:55 |
| J1m | """ | 20:55 |
| J1m | if self._charset is None: | 20:55 |
| J1m | self.setCharset('utf-8') | 20:55 |
| J1m | if self.getHeader('content-type', '').startswith('text'): | 20:56 |
| J1m | data = self._encode(data) | 20:56 |
| J1m | self._updateContentLength(data) | 20:56 |
| J1m | self.write(data) | 20:56 |
| J1m | actually, I'm confused | 20:56 |
| J1m | output calls write | 20:56 |
| J1m | ok, write writes to the outstream | 20:56 |
| SteveA | ah, okay. that's not what i have. i should update. | 20:56 |
| J1m | Note that, someday, I'd like to revisit this in light of wsgi | 20:56 |
| SteveA | yeah | 20:56 |
| SteveA | when the headers are sent, content-length is set even when write() was used directly, at least in the code I'm looking at | 20:56 |
| SteveA | i think that when write was used directly, content-length shouldn't be set unless it was explicitly set | 20:57 |
| J1m | Really, streaming output really needs to be thought through | 20:57 |
| J1m | It's hard because you have to provide a content length | 20:57 |
| SteveA | you don't have to. you just should. | 20:57 |
| J1m | So, if you don't know it. you have to use chunking | 20:57 |
| J1m | No, you really have to. | 20:57 |
| J1m | I'm 99% sure the spec says you must | 20:57 |
| SteveA | http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13 | 20:58 |
| SteveA | definitely a should, not a must | 20:58 |
| SteveA | and, in one thing one of my chaps is trying to do, we can't -- it is generating a tar file on the fly and serving it up based on data in a database | 20:58 |
| J1m | You could use the chunking protocol | 20:59 |
| SteveA | hmm... looks complex | 21:00 |
| * J1m shrugs | 21:00 | |
| J1m | anway, write doesn't seem to enforce that it is set | 21:01 |
| *** sashav has joined #zope3-dev | 21:02 | |
| J1m | oe maybe it does ... | 21:02 |
| SteveA | i'll upgrade the zope3 we're using and see if we're still having a problem | 21:02 |
| SteveA | the code i'm looking at is quite aggressive about adding a content-length header if there is none set | 21:03 |
| J1m | actually, it does set the content length. | 21:03 |
| J1m | I'd be OK with changing this. | 21:04 |
| J1m | Except in the case of the output method, there's really no right way to guess the content length. | 21:04 |
| SteveA | so, move the guessing from getHeaders() into output() | 21:05 |
| J1m | I'd really like to see a thoughtful streaming proposal. | 21:05 |
| *** tvon|x31 has joined #zope3-dev | 21:05 | |
| SteveA | and so, it won't effect using write() | 21:05 |
| J1m | something like that | 21:05 |
| * J1m doesn't want to figure out the details :) | 21:05 | |
| SteveA | would a streaming proposal include chunking stuff? | 21:05 |
| J1m | yes | 21:05 |
| *** tvon has quit IRC | 21:06 | |
| *** tvon|x31 is now known as tvon | 21:06 | |
| J1m | I also think we need to take a harder look at output. | 21:06 |
| J1m | But that's beside the point. | 21:06 |
| J1m | A streaming protocol should do something efficient when handed a file-like object. | 21:06 |
| J1m | And, of course, it should take wsgi into account. | 21:07 |
| * SteveA wonders whether twisted has solved this one already | 21:07 | |
| SteveA | thanks jim. | 21:08 |
| *** gintas has joined #zope3-dev | 21:31 | |
| *** sashav_ has joined #zope3-dev | 21:32 | |
| *** sashav_ has quit IRC | 21:40 | |
| *** sashav has quit IRC | 21:48 | |
| *** apoirier has quit IRC | 21:49 | |
| *** senra has left #zope3-dev | 21:53 | |
| *** gintas has quit IRC | 22:05 | |
| *** tvon has quit IRC | 22:30 | |
| *** niemeyer has quit IRC | 22:39 | |
| *** Aiste has quit IRC | 22:40 | |
| *** sashav has joined #zope3-dev | 22:45 | |
| *** RaFromBRC has joined #zope3-dev | 22:53 | |
| *** bskahan has quit IRC | 23:26 | |
| *** srichter has joined #zope3-dev | 23:49 | |
| *** mgedmin has quit IRC | 23:56 | |
| *** ChanServ sets mode: +o srichter | 23:57 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!