| *** SureshZ has joined #zope3-dev | 00:09 | |
| *** projekt01 has quit IRC | 00:09 | |
| *** projekt01 has joined #zope3-dev | 00:09 | |
| *** hazmat has quit IRC | 00:16 | |
| *** mohsenX has quit IRC | 00:24 | |
| *** Aiste has quit IRC | 00:25 | |
| *** SteveA__ has joined #zope3-dev | 00:30 | |
| *** SteveA has quit IRC | 00:36 | |
| *** projekt01 has quit IRC | 00:44 | |
| *** watzo has quit IRC | 01:07 | |
| *** Aiste has joined #zope3-dev | 01:10 | |
| *** J1m|away has quit IRC | 01:12 | |
| *** hazmat has joined #zope3-dev | 01:14 | |
| *** niemeyer has quit IRC | 01:22 | |
| *** tarek_ has joined #zope3-dev | 01:25 | |
| *** hazmat has quit IRC | 01:34 | |
| *** SureshZ has quit IRC | 01:48 | |
| *** Aiste has quit IRC | 01:51 | |
| *** BjornT has quit IRC | 02:14 | |
| *** BjornT has joined #zope3-dev | 02:14 | |
| *** stub has joined #zope3-dev | 02:16 | |
| *** BjornT has quit IRC | 02:26 | |
| *** hazmat has joined #zope3-dev | 02:35 | |
| *** tarek_ has quit IRC | 02:37 | |
| *** hazmat has quit IRC | 03:07 | |
| *** BjornT has joined #zope3-dev | 03:11 | |
| *** hazmat has joined #zope3-dev | 03:26 | |
| *** jdz_ has joined #zope3-dev | 03:46 | |
| *** hazmat has left #zope3-dev | 04:12 | |
| *** jdz_ has quit IRC | 04:18 | |
| *** alga has quit IRC | 05:37 | |
| *** viyyer has joined #zope3-dev | 07:02 | |
| *** `anthony has quit IRC | 07:14 | |
| *** `anthony has joined #zope3-dev | 07:26 | |
| BjornT | \ | 08:01 |
|---|---|---|
| *** BjornT has quit IRC | 08:02 | |
| *** d2m has quit IRC | 08:02 | |
| *** d2m has joined #zope3-dev | 08:18 | |
| *** zagy has joined #zope3-dev | 08:26 | |
| zagy | moin | 08:54 |
| *** hdima has joined #zope3-dev | 09:20 | |
| *** `anthony has quit IRC | 09:25 | |
| *** zagy has quit IRC | 09:30 | |
| *** sashav has joined #zope3-dev | 10:10 | |
| *** watzo has joined #zope3-dev | 10:39 | |
| *** projekt01 has joined #zope3-dev | 10:39 | |
| *** ignas|away has quit IRC | 10:53 | |
| *** d2m has quit IRC | 11:00 | |
| *** zagy has joined #zope3-dev | 11:03 | |
| *** Aiste has joined #zope3-dev | 11:07 | |
| *** MrTopf has joined #zope3-dev | 11:11 | |
| MrTopf | hi | 11:12 |
| projekt01 | Good morning | 11:28 |
| *** stub has quit IRC | 11:34 | |
| *** SteveA__ is now known as SteveA | 12:00 | |
| *** __gotcha has joined #zope3-dev | 12:20 | |
| *** d2m has joined #zope3-dev | 12:29 | |
| *** d2m has quit IRC | 13:02 | |
| *** d2m has joined #zope3-dev | 13:13 | |
| *** __gotcha has quit IRC | 13:38 | |
| *** MalcolmC has joined #zope3-dev | 13:43 | |
| *** bskahan has quit IRC | 14:19 | |
| *** tav|offline has quit IRC | 14:19 | |
| *** bskahan has joined #zope3-dev | 14:19 | |
| *** tav|offline has joined #zope3-dev | 14:19 | |
| *** tav|offline has quit IRC | 14:20 | |
| *** tav|offline has joined #zope3-dev | 14:20 | |
| *** faassen has joined #zope3-dev | 14:21 | |
| *** __gotcha has joined #zope3-dev | 14:25 | |
| *** srichter has quit IRC | 14:26 | |
| *** niemeyer has joined #zope3-dev | 14:31 | |
| *** povbot has joined #zope3-dev | 14:47 | |
| *** andrew_m has joined #zope3-dev | 14:50 | |
| *** SureshZ has joined #zope3-dev | 14:54 | |
| *** viyyer has quit IRC | 15:03 | |
| *** tav|offline has quit IRC | 15:03 | |
| *** bskahan has quit IRC | 15:03 | |
| *** tav|offline has joined #zope3-dev | 15:04 | |
| *** bskahan has joined #zope3-dev | 15:04 | |
| *** tav|offl1ne has joined #zope3-dev | 15:05 | |
| *** tav|offline has quit IRC | 15:05 | |
| *** srichter has joined #zope3-dev | 15:09 | |
| *** ChanServ sets mode: +o srichter | 15:10 | |
| *** bskahan has quit IRC | 15:30 | |
| *** bskahan has joined #zope3-dev | 15:31 | |
| *** BjornT has joined #zope3-dev | 15:40 | |
| *** bskahan has quit IRC | 15:46 | |
| *** bskahan has joined #zope3-dev | 15:46 | |
| *** MalcolmC has quit IRC | 15:52 | |
| *** bskahan has quit IRC | 15:53 | |
| *** bskahan has joined #zope3-dev | 15:57 | |
| *** tarek_ has joined #zope3-dev | 16:10 | |
| *** MalcolmC has joined #zope3-dev | 16:10 | |
| *** bradb has quit IRC | 16:15 | |
| *** SureshZ has quit IRC | 16:22 | |
| *** BjornT has quit IRC | 16:22 | |
| *** bradb has joined #zope3-dev | 16:34 | |
| *** SteveA_ has joined #zope3-dev | 16:38 | |
| *** SteveA_ has quit IRC | 16:42 | |
| *** BjornT has joined #zope3-dev | 16:42 | |
| *** Ragica has quit IRC | 16:43 | |
| *** SteveA_ has joined #zope3-dev | 16:45 | |
| *** hdima has quit IRC | 16:47 | |
| *** SteveA has quit IRC | 16:47 | |
| *** J1m has joined #zope3-dev | 16:48 | |
| *** Ragica has joined #zope3-dev | 16:49 | |
| SteveA_ | hi J1m | 17:00 |
| *** SteveA_ is now known as SteveA | 17:00 | |
| J1m | hi | 17:01 |
| SteveA | are you still good to talk about pre-render hooks on views? | 17:01 |
| J1m | yes | 17:01 |
| *** GaryPoster has joined #zope3-dev | 17:02 | |
| J1m | Hoping Gary will join us | 17:02 |
| J1m | There he is | 17:02 |
| SteveA | hi gary | 17:02 |
| J1m | OK | 17:02 |
| GaryPoster | hi Steve | 17:02 |
| SteveA | I've had two interesting problems recently. I'm hoping to address at least one of them here. | 17:02 |
| J1m | My grand design is to have something like CMFFormController for Zope 3. | 17:02 |
| SteveA | maybe i can start by briefly describing the problems? | 17:02 |
| J1m | My related grand design is to split actual rendering/publishing into multiple steps. | 17:03 |
| J1m | Sure, go ahead | 17:03 |
| * J1m unfortunately, has very little time these days to work on grand designs. :) | 17:04 | |
| SteveA | thanks. the first is, i want to have some code run before a Page gets rendered. often, this is stuff that processes a form's response. | 17:04 |
| SteveA | but sometimes, it is set-up code for the page template. | 17:04 |
| SteveA | i don't want to do either in the __init__, as this causes various problems | 17:05 |
| SteveA | like heavy processing occuring by just asking for a view. | 17:05 |
| SteveA | the second is, i want to mark a content object with certain marker interfaces, depending on the object's state, and also on the request or the interaction. | 17:06 |
| SteveA | i need to do this before views are looked up. | 17:06 |
| SteveA | but, i don't want to do that when objects are loaded, because the marker interfaces to use depends on presentation things. | 17:06 |
| SteveA | that is, the marker interface to use is not intrinsic to the state of the object. | 17:06 |
| * SteveA is done | 17:06 | |
| GaryPoster | so, these markers are temporary, only for the request? | 17:07 |
| SteveA | (i'm on a laggy connection, so please bear with me if i seem slow to respond sometimes) | 17:07 |
| SteveA | yes | 17:07 |
| J1m | This (2nd) feels very weird to me | 17:08 |
| GaryPoster | Also, marius suggested __call__ rather than __init__; what are its drawbacks for your purposes (the first use case you raised) | 17:08 |
| SteveA | J1m: yes. i didn't come up with it. i'm currently looking at whether to keep it, or to do something different. | 17:08 |
| SteveA | J1m: so, i'm not bothered if we skip the 2nd case. | 17:08 |
| J1m | Cool :) | 17:08 |
| J1m | I'd be happy to discuss the motivation for the 2nd case a little later. | 17:09 |
| SteveA | thanks. | 17:09 |
| SteveA | GaryPoster: do you mean calling __call__ on a view's class if it is present, before rendering a view's page? | 17:10 |
| SteveA | s/page/template/ | 17:10 |
| J1m | Things brings us to a related topic. :) | 17:11 |
| J1m | We currently don't have a defined interface for published objects. | 17:11 |
| J1m | The informal interface is that published objects are called (via mapply) | 17:12 |
| J1m | I want to change this for X3.2. | 17:12 |
| J1m | So anyway, publish objects are called. | 17:12 |
| GaryPoster | Maybe I'm remembering incorrectly, but I thought the API for rendering a a view class was __call__; this usually renders the template but a view class could step in front and do preprocessing...but Jim is addressing this... :-) | 17:12 |
| J1m | The current page and form machinery arrange that __call__ is a call to the template. | 17:12 |
| J1m | But, of course, we could do something else. | 17:13 |
| SteveA | how does __call__ say "now render the template" ? | 17:13 |
| J1m | The __call__ of most views (produced by page or forms) just calles the template. | 17:14 |
| J1m | The __call__ of most views (produced by page or forms) just calls the template. | 17:14 |
| SteveA | so, if i override __call__, how do i say "now render the template" ? | 17:14 |
| J1m | I couldn't tell you off had. | 17:15 |
| J1m | I could look it up. | 17:15 |
| J1m | It *might* be the same accross different mechanisms (pages, and forms), but it might not, as it's not currently part of the api. | 17:16 |
| J1m | We could arrange that the template has a well-defined name, so you could override __call__ and call it. | 17:16 |
| SteveA | i like the idea of explicitly saying "now render the page" from an explicit __call__, as that would allow you to not render the page if for example you're doing a redirect. | 17:17 |
| J1m | Sure, or rendering a different page. | 17:17 |
| J1m | So, perhaps the easiest way to do this is by overriding call? | 17:18 |
| J1m | (At least in the short term.) | 17:18 |
| GaryPoster | It feels nice and simple to me. | 17:18 |
| J1m | And we arrange that the template is exposed with a well-known name? | 17:18 |
| J1m | me too. | 17:18 |
| SteveA | that would solve both my first cases, provided there's a clear way to say "render the page" | 17:18 |
| J1m | Leaves room for grander plans in 3.2. :) | 17:19 |
| J1m | It addresses all 5 of my first cases. ;) | 17:19 |
| GaryPoster | I like that too. The render the page would be i.e. self.template() | 17:19 |
| GaryPoster | (return that :-) ) | 17:20 |
| SteveA | so, how will a __call__ method look, that sets up some state for the template to use? | 17:20 |
| SteveA | def __call__(self): | 17:20 |
| SteveA | self.set_up_the_state() | 17:20 |
| J1m | I think the default __call__ is: | 17:20 |
| SteveA | ??? | 17:20 |
| J1m | def __call__(self): | 17:20 |
| J1m | self.template() | 17:20 |
| J1m | 17:20 | |
| GaryPoster | return self.template() | 17:20 |
| J1m | Anything else is up to you. | 17:20 |
| J1m | yes | 17:20 |
| J1m | sorry | 17:21 |
| GaryPoster | So you might have a mixin view class that was | 17:21 |
| GaryPoster | def __call__(self): | 17:21 |
| SteveA | okay | 17:21 |
| SteveA | so, i could grab the output of self.template() and do stuff to it | 17:21 |
| SteveA | before returning it | 17:21 |
| J1m | yes | 17:21 |
| GaryPoster | # do your set up, setting attributes on the view and possibly sending things to the options of the template call | 17:21 |
| GaryPoster | and then the return self.template(*maybe_you_have_options) | 17:22 |
| SteveA | what kind of object is self.template() ? | 17:22 |
| SteveA | what kind of object is self.template ? | 17:23 |
| J1m | A ViewPageTemplateFile. | 17:23 |
| *** stub has quit IRC | 17:23 | |
| SteveA | self.template() is string data. (as in, str, pretending to be binary data) | 17:23 |
| GaryPoster | self.template: page template; self.template(): unicode | 17:23 |
| SteveA | I don't think you can pass options to a ViewPageTemplateFile | 17:23 |
| J1m | Yes, you can | 17:23 |
| J1m | I'm 90% sure you can | 17:23 |
| SteveA | do I return unicode or str from __call__ ? | 17:23 |
| J1m | as keyword arguments | 17:24 |
| GaryPoster | I know I've done this sort of thing :-) | 17:24 |
| J1m | unicode (or it's a bug) | 17:24 |
| J1m | The encoding is done by the publisher. | 17:24 |
| SteveA | so, if __call__ wants to return image data, it uses response.setBody() ? | 17:24 |
| J1m | I don't know off hand. Look at image objects. :) | 17:25 |
| GaryPoster | (I don't know; I'd look at the Image implementation) | 17:25 |
| projekt01 | I think call self.template() will process the page template, right? | 17:26 |
| GaryPoster | right | 17:26 |
| SteveA | FileView has a show() method | 17:27 |
| SteveA | that returns self.context.data after setting the content-type and content-length headers | 17:27 |
| J1m | That method is probably listed as an attribute in the zcml. | 17:27 |
| SteveA | it is hooked up with a browser:page that uses a class and attribute | 17:27 |
| SteveA | so, using a class+attribute means you return str data. using a class+template means you return unicode. | 17:28 |
| *** benji_york has joined #zope3-dev | 17:28 | |
| SteveA | if that's right, that seems rather implicit | 17:29 |
| J1m | Keep in mind that we don't have a formal publishing interface. | 17:29 |
| J1m | yes, it is | 17:29 |
| * SteveA invokes the "i" word | 17:29 | |
| J1m | Go ahead | 17:29 |
| SteveA | i never consciously realized it | 17:29 |
| GaryPoster | (uh-oh :-) ) | 17:29 |
| J1m | Sure you did. | 17:29 |
| J1m | You objected to having views provide Interface. | 17:29 |
| J1m | You want us to provide something more specific. | 17:30 |
| J1m | I do too. | 17:30 |
| J1m | I'm afraid I don't have time now to work out what that should be. | 17:30 |
| SteveA | oh that, sure. what i didn't realize was that the publisher expects class+attribute to return something different from class+template | 17:30 |
| J1m | (Plus we need to stop adding features for 3.1.) | 17:30 |
| J1m | The publisher expects calling the objects to return something. | 17:31 |
| J1m | What that something is is undefined. | 17:31 |
| J1m | It's up to the response to make sense of it. | 17:31 |
| SteveA | so, if class+attribute returns a unicode, then the publisher will encode it | 17:31 |
| J1m | For example, XML-RPC responses expect possibly complex data structures to be returned. | 17:31 |
| J1m | Yes (I suppose) | 17:32 |
| SteveA | and if it returns an unencoded str (that is, data), then it assume it is ready-encoded | 17:32 |
| J1m | Presumably | 17:32 |
| * SteveA needs to read the code | 17:32 | |
| SteveA | but, for 3.2, this will be explicit, because there will be an interface for this. | 17:32 |
| J1m | Or perhaps it takes the content type into account | 17:32 |
| J1m | yes | 17:32 |
| SteveA | ok, great. | 17:33 |
| J1m | There are *many* goals in play here. | 17:33 |
| SteveA | this all gives me enough to work with for now | 17:33 |
| SteveA | and get rid of <tal:dummy replace="view/method_to_set_stuff_up_that_returns_empty_string" /> | 17:33 |
| J1m | I was hoping to work this out via the Bobo project I haven't had time to work on. Sigh. | 17:33 |
| J1m | Yup. Us too. | 17:34 |
| *** MrTopf has quit IRC | 17:34 | |
| SteveA | cool. thanks J1m and GaryPoster. | 17:34 |
| J1m | So, now we need someone to implement what we talked about. :) | 17:34 |
| J1m | Any volunteers? | 17:34 |
| GaryPoster | :-) Good to hear from you SteveA | 17:34 |
| SteveA | what's there to implement? | 17:34 |
| * J1m cups his hand by his ear | 17:34 | |
| SteveA | an interface for views' classes? | 17:35 |
| J1m | No | 17:35 |
| J1m | A template attribute define by the page and form directives | 17:35 |
| J1m | Making sure that people can override __call__ the way we described. | 17:35 |
| SteveA | okay, put me on the hook for that | 17:36 |
| GaryPoster | Jim is looking at me like I want to volunteer, maybe | 17:36 |
| GaryPoster | ok, cool | 17:36 |
| GaryPoster | :-) | 17:37 |
| J1m | Cool Steve | 17:37 |
| SteveA | do you have time to talk about the 2nd issue i mentioned? | 17:39 |
| J1m | sure | 17:39 |
| SteveA | so, in this system, objects are not cached between requests | 17:39 |
| SteveA | there are different views on an IReadOnlyFoo and an IEditableFoo. Both interfaces extend IFoo. | 17:40 |
| SteveA | currently, the system that loads objects considers the state of a Foo that is being loaded, and the logged-in user, and marks the Foo with either IReadOnlyFoo or IEditableFoo | 17:41 |
| SteveA | my main complaint about this currently is that content code is taking the interaction into account when setting interfaces on content objects. | 17:42 |
| SteveA | i can fix that by using events, and having an event handler that activates on on loading a Foo, that is registered from "presentation" space. | 17:42 |
| SteveA | but, i'm dubious about the whole notion of temporarily marking objects like that, taking into account the interaction | 17:43 |
| SteveA | i'm quite happy with marking objects taking into account only their own universal state | 17:43 |
| SteveA | one thing i could do is to decorate the Foo object with a temporary decorator, before it gets to be published | 17:46 |
| SteveA | the decorator can be editable or read-only | 17:46 |
| GaryPoster | what sort of presentation decisions do you need to make? | 17:46 |
| * J1m doesn't want to interrupt | 17:46 | |
| GaryPoster | (Gary interrupted happily :-) ) | 17:47 |
| * SteveA had finished, but forgot to say | 17:50 | |
| J1m | I agree with your assessment. | 17:50 |
| J1m | I'm wondering what the motivation for this is. | 17:51 |
| J1m | Is it to provide different UI depending on the priviledges of the user? | 17:51 |
| SteveA | yes | 17:51 |
| J1m | Of course, we do this now by electing different views depending on priviledges. | 17:53 |
| J1m | Of course, we do this now by selecting different views depending on priviledges. | 17:53 |
| SteveA | i don't follow | 17:53 |
| J1m | @@selectedManagementView picks the first view for them that they can see | 17:54 |
| J1m | We only show links to views they can see. | 17:54 |
| SteveA | oh, right, in the zmi | 17:54 |
| J1m | (The former then uses a redirect.) | 17:55 |
| SteveA | so, one principle i should consider is that if the presentation for read-only and for edit is radically different enough to want a different page implementation, than maybe it wants a different URL too | 17:56 |
| J1m | What you really have is a relationship between 2 objects. | 17:56 |
| J1m | yes | 17:56 |
| J1m | You have a relationship between an object and an interaction. | 17:57 |
| J1m | You want to choose the view based on that relationship. | 17:57 |
| J1m | Your decorator idea sort of captures that. | 17:57 |
| SteveA | i see | 18:00 |
| SteveA | yeah, the decorator could be considered a view itself. | 18:00 |
| SteveA | it depends on IFoo and the interaction | 18:00 |
| J1m | yes | 18:00 |
| SteveA | and provides IFoo | 18:00 |
| SteveA | decorated with something else that extends IFoo | 18:01 |
| SteveA | thanks jim. that gives me a bunch of stuff to think about. | 18:02 |
| J1m | It could be argues that this is a case where Eby's predicate dispatching would be useful. | 18:02 |
| J1m | You want to select view X if the type is T and you have permission P. | 18:02 |
| J1m | You want to select view Y if the type is T and you don't have permission P. | 18:02 |
| * SteveA doesn't see it yet | 18:03 | |
| * SteveA was lagged | 18:04 | |
| * J1m just BSing ;) | 18:04 | |
| J1m | You could register a factory that selects another factory based in access rights | 18:04 |
| SteveA | that's an interesting idea | 18:05 |
| J1m | You could register a factory that selects another factory based on access rights | 18:05 |
| SteveA | for example, i could have a kind of view that is selected not on (context, request, name) but (context, request, name, permission) | 18:05 |
| J1m | This would be a combination of type-based dispatching and predicate-based dispatching. | 18:05 |
| J1m | right | 18:06 |
| SteveA | where permission isn't really part of the tuple, but is actually a predicate | 18:06 |
| J1m | yup | 18:06 |
| J1m | I'm not suggesting this, just thinking out loud. | 18:06 |
| SteveA | i already have some decent support for decorators | 18:07 |
| J1m | What I like about this is that it seems concpetually cleaner than interaction-based interface hacks or even decorators. | 18:07 |
| SteveA | so i'll consider that one first | 18:07 |
| J1m | cool | 18:07 |
| J1m | OK, I need to get back to work. | 18:07 |
| *** J1m is now known as J1m|away | 18:07 | |
| SteveA | i could easily add a one-off view that dispatches to one of several other views based on permissions | 18:07 |
| SteveA | so, if it is a one-off, then i can do that | 18:07 |
| SteveA | thanks again. plently of options now. | 18:08 |
| *** vlado has joined #zope3-dev | 18:11 | |
| *** bskahan has quit IRC | 18:35 | |
| *** bskahan has joined #zope3-dev | 18:45 | |
| *** Aiste has quit IRC | 18:45 | |
| *** sashav has quit IRC | 18:46 | |
| *** apoirier has joined #zope3-dev | 18:52 | |
| *** vlado has quit IRC | 18:57 | |
| *** vlado has joined #zope3-dev | 19:02 | |
| *** Theuni has quit IRC | 19:12 | |
| *** Aiste has joined #zope3-dev | 19:16 | |
| *** vlado has quit IRC | 19:20 | |
| *** MalcolmC has quit IRC | 19:38 | |
| *** bskahan has quit IRC | 20:04 | |
| *** bskahan has joined #zope3-dev | 20:15 | |
| *** alga has joined #zope3-dev | 20:37 | |
| *** alga_ has joined #zope3-dev | 20:40 | |
| *** alga_ has quit IRC | 20:43 | |
| *** ignas_ is now known as ignas | 20:53 | |
| *** apoirier has quit IRC | 21:01 | |
| *** alga has quit IRC | 21:06 | |
| *** faassen has left #zope3-dev | 21:18 | |
| *** bskahan has quit IRC | 21:23 | |
| *** tvon has quit IRC | 21:28 | |
| *** bskahan has joined #zope3-dev | 21:37 | |
| *** GaryPoster has quit IRC | 21:48 | |
| *** sunhome has joined #zope3-dev | 21:54 | |
| *** sunhome has left #zope3-dev | 21:55 | |
| *** bskahan has quit IRC | 22:12 | |
| projekt01 | SteveA, did you see the pagelet implementation? | 22:20 |
| *** Aiste has quit IRC | 22:23 | |
| *** SteveA__ has joined #zope3-dev | 22:39 | |
| SteveA__ | projekt01: nope | 22:40 |
| SteveA__ | projekt01: got some urls or paths in a checkout to point me at? | 22:40 |
| projekt01 | zope.app.pagelet | 22:40 |
| projekt01 | And zope.app.pageletchooser | 22:41 |
| SteveA__ | what is a pagelet? | 22:41 |
| * SteveA__ reads the README.txt | 22:41 | |
| projekt01 | ZPT code registred as a adapter which can be used in another page template | 22:42 |
| SteveA__ | thanks, I'll take a look | 22:42 |
| projekt01 | Ok | 22:42 |
| projekt01 | See also zope.app.boston, this experimental skin use this pagelets | 22:43 |
| SteveA__ | okay | 22:44 |
| *** SteveA has quit IRC | 22:44 | |
| *** SteveA__ is now known as SteveA | 22:44 | |
| projekt01 | There is also a demo package zope.app.demo.pagelet / pageletchooser | 22:46 |
| *** tvon has joined #zope3-dev | 22:53 | |
| *** Aiste has joined #zope3-dev | 23:02 | |
| *** GaryPoster has joined #zope3-dev | 23:09 | |
| *** BjornT has quit IRC | 23:35 | |
| *** BjornT has joined #zope3-dev | 23:35 | |
| *** watzo has quit IRC | 23:40 | |
| *** __gotcha_ has joined #zope3-dev | 23:53 | |
| *** __gotcha has quit IRC | 23:57 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!