| *** __gotcha__ is now known as __gotcha | 00:00 | |
| *** Aiste has quit IRC | 00:00 | |
| *** ignas_ is now known as ignas | 00:12 | |
| *** __gotcha is now known as __gotchaway | 00:24 | |
| *** SureshZ has quit IRC | 00:26 | |
| *** jhauser has quit IRC | 00:33 | |
| *** GaryPoster has quit IRC | 01:01 | |
| *** `anthony has quit IRC | 01:02 | |
| projekt01 | J1m, do you really propose not to use LocationProxy and implement ILocation in trusted adapters? | 01:04 |
|---|---|---|
| projekt01 | J1m, I'm pretty sure that I run into this problem because we get the object form a LocationProxyContainer where our objects already proxied with LocationProxy | 01:52 |
| projekt01 | I think we can solve the problem if we could remove this LocationProxy and add a new LocationProxy in the LocationProxyContainer | 01:53 |
| J1m | projekt01, It is very risky to be removing proxies. | 01:58 |
| J1m | I don't want to go there. | 01:59 |
| J1m | I don't know what the code in editview.py is trying to do. | 01:59 |
| projekt01 | I think I get doubled proxies, but I'm not sure right now. | 01:59 |
| *** benji_york has quit IRC | 01:59 | |
| J1m | Yes, you are getting double proxies, but what is that code in editview trying to accomplish? | 01:59 |
| J1m | Do you know? | 02:00 |
| J1m | srichter, do you know? | 02:00 |
| projekt01 | Give a location for editing the object and make the events working. I think | 02:01 |
| srichter | here, I am reading up... | 02:01 |
| projekt01 | notify(ObjectModifiedEvent(content)) | 02:01 |
| J1m | The events don't need the adapter to have a __parent__ | 02:02 |
| srichter | I did follow todays discussion , so I am at a lost | 02:03 |
| J1m | I haven't followed the details either. | 02:04 |
| J1m | But it revolves around ... | 02:04 |
| projekt01 | Was there in the past something which needs a Location on editing a object in the edit view? I'm sure removing Location proxy out of the edit view wasn't possible before. Now it seems to work | 02:04 |
| J1m | def _setUpWidgets(self): | 02:04 |
| J1m | adapted = self.schema(self.context) | 02:04 |
| J1m | if adapted is not self.context: | 02:04 |
| J1m | if not ILocation.providedBy(adapted): | 02:04 |
| J1m | adapted = LocationProxy(adapted) | 02:04 |
| J1m | adapted.__parent__ = self.context | 02:04 |
| J1m | self.adapted = adapted | 02:04 |
| J1m | setUpEditWidgets(self, self.schema, source=self.adapted, | 02:04 |
| J1m | names=self.fieldNames) | 02:04 |
| J1m | in editview.py | 02:04 |
| J1m | specifically, the business with the location proxy. | 02:05 |
| J1m | I don't know who added that code, but I have no idea what it was intended to do and it's causing problems now. | 02:05 |
| J1m | projekt01, there are three possibilities: | 02:06 |
| projekt01 | I listen | 02:06 |
| J1m | 1. It could help with security *if* the adapter was not already proxied and if something in the editview code was going to proxy it. The former isn't always true, as you found out. The later wasn't true until recently, so I don't think security is the reason. | 02:07 |
| J1m | 2. It could have been for component lookup in the distant past. The lines are old enough that that is the most likely explanation. This certainly isn't an issue now. | 02:08 |
| J1m | 3. If the adapter, or more specifically, the fields or widgets need to acquire something, then __parent__ would be necessary. But, in that unusual case, the author of the adapter could set __parent__ in the constructor. | 02:10 |
| J1m | over | 02:10 |
| projekt01 | I think No. 2 I can checkout, I try to remove it run all tests and commit it to the trunk. I think it's Ok, if we add the Ilocation to the adapter if needed. | 02:11 |
| J1m | That's my opinion too. :) | 02:12 |
| projekt01 | I try it, I send you a note if I see other problems, thanks | 02:13 |
| J1m | k, thanks | 02:13 |
| J1m | so basically, we're talking about removing: | 02:13 |
| J1m | if adapted is not self.context: | 02:13 |
| J1m | if not ILocation.providedBy(adapted): | 02:13 |
| J1m | adapted = LocationProxy(adapted) | 02:13 |
| J1m | adapted.__parent__ = self.context | 02:13 |
| projekt01 | Yes | 02:13 |
| J1m | cool | 02:14 |
| projekt01 | If it's working and all test will run ;-) | 02:14 |
| J1m | well, they probably won't. | 02:14 |
| J1m | I suspect that there are tests for those lines. | 02:14 |
| J1m | The question is whether the tests will reveal the intent. | 02:15 |
| projekt01 | I'll check it | 02:15 |
| projekt01 | Is there a method like isTrusted() similar to isProxy() or how can I test if a adapter is trusted? | 02:19 |
| J1m | why do you care? | 02:19 |
| projekt01 | I'm not really sure what the object is which fails in my usecase | 02:19 |
| projekt01 | This proxies are really little secrets | 02:20 |
| J1m | One way to spot a trusted adapter is that it is security proxied. Normally, adapters aren't security proxied unless they are passed to untrusted code. | 02:20 |
| projekt01 | Hm, if I print out the object I get: self.adapted <amadeus.internet.dom.adapters.HTMLDocumentI18nSwitchForInternetDocument object at 0x03ADF5F0> | 02:22 |
| projekt01 | If I test it like isProxy(adapted) I get True | 02:22 |
| projekt01 | This means it's a trusted adapter. This whould be correct, it is. | 02:23 |
| J1m | It is most likely a trusted adapter. | 02:23 |
| J1m | Can't you tell by looking at the zcml? | 02:24 |
| projekt01 | Yes it is a trusted adapter in zcml | 02:24 |
| J1m | BTW, the easiest way to tell if something is security proxied is to look at type(ob) | 02:25 |
| *** `anthony has joined #zope3-dev | 02:25 | |
| projekt01 | Ok I see, but there I can't see if it's a trusted adapter, right? | 02:27 |
| projekt01 | adapted <amadeus.internet.dom.adapters.HTMLDocumentI18nSwitchForInternetDocument object at 0x03ADF570> | 02:27 |
| projekt01 | isProxy(adapted) True | 02:27 |
| projekt01 | type(adapted) <type 'zope.security._proxy._Proxy'> | 02:27 |
| J1m | all you can tell is that it's a security proxy. You can't tell if it got that way by being trusted. | 02:28 |
| J1m | Why do you need to know if it is trusted? | 02:28 |
| projekt01 | I like to understand what's going on. | 02:28 |
| projekt01 | ;-) | 02:28 |
| J1m | OK | 02:29 |
| projekt01 | Perhaps there is another problem, because we us a LocationProxyContainer which proxies ites item | 02:29 |
| J1m | Well, if you get a proxied object from an adapter lookup today, it was almost certainly a trusted adapter. | 02:29 |
| J1m | I don't know what you mean. | 02:30 |
| projekt01 | We use a ICOntainer implementation which proxies it's item. This makes it possible to show a object on another location too | 02:31 |
| projekt01 | This is the base concept of our framework | 02:31 |
| J1m | Proxies suck. | 02:31 |
| *** tvon|desk has quit IRC | 02:31 | |
| J1m | They are sometimes-necessary deep black magic. | 02:32 |
| J1m | if you go there, be prepared for pain. :) | 02:32 |
| projekt01 | Yup | 02:32 |
| J1m | I avoid them whenever I can. | 02:32 |
| J1m | But we too use proxies to allow objects to be in multiple places. | 02:32 |
| projekt01 | But if it's working you can do incredible things | 02:33 |
| projekt01 | Yup that's ecaxtly what I mean we have to show the object in different locations | 02:33 |
| J1m | We have symbolic-link-like objects that create proxies when they are traversed so application code can determine access paths, for example for generating bread crumbs. | 02:33 |
| J1m | These haven't run afoul of the security machinery. | 02:34 |
| projekt01 | Ah right, breadcrumb was also a part that doesn't work without location. | 02:35 |
| projekt01 | J1m, all tests are Ok, if I comment out the part in the editview | 02:36 |
| projekt01 | #if adapted is not self.context: | 02:36 |
| projekt01 | # if not ILocation.providedBy(adapted): | 02:36 |
| projekt01 | # adapted = LocationProxy(adapted) | 02:36 |
| projekt01 | # adapted.__parent__ = self.context | 02:36 |
| J1m | awesome | 02:37 |
| projekt01 | Should I commit it? | 02:37 |
| J1m | yup | 02:37 |
| projekt01 | Ok, I will cklick arround the ZMI first, to make sure all is working fine in reality. | 02:38 |
| J1m | :) | 02:38 |
| projekt01 | srichter, If I set the frontpage in the wiki to the parent of itself I get maximum recursion error. | 02:44 |
| projekt01 | Like: | 02:44 |
| projekt01 | RuntimeError: maximum recursion depth exceeded | 02:44 |
| *** J1m has quit IRC | 02:51 | |
| srichter | yep | 02:56 |
| projekt01 | I found a exactly description in the adding.py view which describes the problem which I have. | 02:57 |
| projekt01 | # TODO: If the factory wrapped by LocationProxy is already a Proxy, | 02:57 |
| projekt01 | # then ProxyFactory does not do the right thing and the | 02:57 |
| projekt01 | # original's checker info gets lost. No factory that was | 02:57 |
| projekt01 | # registered via ZCML and was used via addMenuItem worked | 02:57 |
| projekt01 | # here. (SR) | 02:57 |
| projekt01 | srichter, ;-) | 02:57 |
| projekt01 | I'll post it to the mailing list and add it to the commit message | 02:57 |
| srichter | I think I never implemented the recursive linking prevention in the wiki code | 02:57 |
| srichter | yeah, I remember the problem | 02:58 |
| srichter | it was fairly deep | 02:58 |
| projekt01 | Yup, I deeeeeeped today also into this | 02:58 |
| srichter | "deep" is not a verb :-) | 02:59 |
| srichter | you can use "dive" | 03:00 |
| srichter | I dove deep into the issue today | 03:00 |
| projekt01 | Ah, thanks, I really have to learn it once. | 03:01 |
| srichter | "once" should be "at some point" | 03:01 |
| srichter | it works in German, but not in English ;-) - A common German-native speaker mistake ;-) | 03:02 |
| projekt01 | ;-) | 03:02 |
| projekt01 | Hm, Do you use edit wizards? The EditWizardView use also the LocationProxy. | 03:04 |
| projekt01 | Or do you know where they are used? | 03:05 |
| srichter | is anyone using them? :-) | 03:05 |
| srichter | they are not used | 03:05 |
| projekt01 | Ok, I try to remove the LocationProxy also form the EditWizardView. | 03:06 |
| srichter | yeah | 03:07 |
| projekt01 | Hm, Is anyone using the DisplayView? | 03:07 |
| projekt01 | ;-) | 03:07 |
| srichter | the location proxy should not be necessary anymore, since all views must keep track of their parent and name anyways now | 03:07 |
| srichter | yes, this one is used by Zope Corp | 03:07 |
| srichter | Fred has been using it IIRC | 03:08 |
| *** hazmat has quit IRC | 03:08 | |
| projekt01 | IIRC ? | 03:08 |
| *** bskahan has quit IRC | 03:08 | |
| *** bskahan has joined #zope3-dev | 03:11 | |
| srichter | IIRC = if I remember correctly | 03:13 |
| *** tvon has quit IRC | 03:22 | |
| *** hazmat has joined #zope3-dev | 03:45 | |
| *** stub has joined #zope3-dev | 03:56 | |
| *** hazmat has quit IRC | 03:59 | |
| *** projekt01 has left #zope3-dev | 04:22 | |
| *** hazmat has joined #zope3-dev | 04:52 | |
| *** hazmat has quit IRC | 05:55 | |
| *** jack-e|away has quit IRC | 06:01 | |
| *** xena has quit IRC | 06:01 | |
| *** vinsci has quit IRC | 06:01 | |
| *** jack-e|away has joined #zope3-dev | 06:01 | |
| *** xena has joined #zope3-dev | 06:01 | |
| *** vinsci has joined #zope3-dev | 06:01 | |
| *** stub has quit IRC | 06:35 | |
| *** hazmat has joined #zope3-dev | 06:36 | |
| *** Pupeno has joined #zope3-dev | 06:42 | |
| Pupeno | Hello! | 06:42 |
| Pupeno | I have downloaded and compiled (and now, run) zope 3 from svn... I understand that I can put my products on lib/python, but, is there a better way to locate my products so they are separated of Zope ? | 06:43 |
| *** BjornT has quit IRC | 06:44 | |
| *** stub has joined #zope3-dev | 06:50 | |
| *** Pupeno has quit IRC | 07:08 | |
| *** hazmat has quit IRC | 07:48 | |
| *** stub has quit IRC | 08:12 | |
| *** d2m has quit IRC | 08:13 | |
| *** stub has joined #zope3-dev | 08:13 | |
| *** stub has quit IRC | 08:17 | |
| *** stub has joined #zope3-dev | 08:20 | |
| zagy | moin | 08:36 |
| *** stub has quit IRC | 08:43 | |
| *** stub has joined #zope3-dev | 08:43 | |
| *** viyyer has joined #zope3-dev | 08:52 | |
| *** htd has joined #zope3-dev | 08:58 | |
| *** d2m has joined #zope3-dev | 09:04 | |
| *** deo has quit IRC | 09:14 | |
| *** tav|offline has quit IRC | 09:14 | |
| *** hdima has joined #zope3-dev | 09:14 | |
| *** tav|offline has joined #zope3-dev | 09:17 | |
| *** tav|offline has quit IRC | 09:20 | |
| *** tav|offline has joined #zope3-dev | 09:22 | |
| *** jhauser has joined #zope3-dev | 09:52 | |
| *** bskahan has quit IRC | 10:00 | |
| *** vlado|away is now known as vlado | 10:10 | |
| *** hazmat has joined #zope3-dev | 10:30 | |
| *** `anthony has quit IRC | 10:47 | |
| *** `anthony has joined #zope3-dev | 11:00 | |
| *** mgedmin has joined #zope3-dev | 11:19 | |
| *** projekt01 has joined #zope3-dev | 11:19 | |
| projekt01 | mgedmin, did you see the removing of the LocationProxy out of the EditView? | 11:22 |
| mgedmin | not yet | 11:22 |
| projekt01 | mgedmin, can you test the SchoolBell application? | 11:23 |
| mgedmin | SchoolBell uses a frozen snapshot of Zope 3 at the moment | 11:24 |
| mgedmin | I'll take a look at what's this LocationProxy stuff about, thanks for the heads-up | 11:25 |
| projekt01 | Yup | 11:25 |
| *** philiKON has joined #zope3-dev | 11:42 | |
| mgedmin | late night hacking: http://mg.pov.lt/blog/zope3-request-recorder.html | 11:53 |
| philiKON | way cool | 11:55 |
| mgedmin | I need to make it thread-safe and write some unit tests, then I can commit it into zope 3 if there's interest | 11:55 |
| philiKON | yes, a lot | 11:55 |
| philiKON | does it produce doctests already? | 11:55 |
| mgedmin | yes | 11:55 |
| mgedmin | it reuses zope.app.testing.dochttp | 11:56 |
| mgedmin | you click on the 'Create doctest' button and you get a file download window in your browser | 11:56 |
| mgedmin | I need a global data structure that can be accessed (read & write) from multiple threads | 11:56 |
| philiKON | cool | 11:57 |
| mgedmin | I suppose MappingStorage fits the bill best, as I'd also like to have transactions | 11:57 |
| mgedmin | any examples in zope 3? | 11:57 |
| mgedmin | do sessions use something like that? | 11:57 |
| philiKON | yes, a zodb storage would probably be best | 11:58 |
| philiKON | mgedmin, sessions uses mappingstorage | 11:59 |
| projekt01 | mgedmin, whow | 11:59 |
| mgedmin | ok, I see how RAMSessionDataContainer does this | 12:01 |
| *** philiKON has quit IRC | 12:02 | |
| mgedmin | next question: how do I allocate unique small numeric IDs from multiple threads without causing too many conflict errors? | 12:03 |
| *** tarek_ is now known as tarek_away | 12:10 | |
| *** MalcolmC has joined #zope3-dev | 12:11 | |
| *** Aiste has joined #zope3-dev | 12:17 | |
| *** tarek__ has joined #zope3-dev | 13:42 | |
| *** tarek_away has quit IRC | 13:50 | |
| *** vlado has quit IRC | 14:06 | |
| *** __gotcha has joined #zope3-dev | 14:14 | |
| *** philiKON has joined #zope3-dev | 14:24 | |
| SteveA | mgedmin: i don't understand | 14:33 |
| *** srichter has quit IRC | 14:34 | |
| SteveA | mgedmin: i'd suggest using a many-read-one-write lock on a module-level object. | 14:34 |
| mgedmin | on every request I want to add an object to a container | 14:35 |
| mgedmin | I would like the objects to have unique short IDs | 14:35 |
| mgedmin | so that I can refer to them in web forms | 14:36 |
| SteveA | you may want to write a container that is for appending only, and knows about conflict resolution | 14:36 |
| SteveA | and allocates its own ids | 14:36 |
| mgedmin | ah, good idea | 14:36 |
| mgedmin | I've never written a persisten class that handled conflict resolution smartly | 14:37 |
| mgedmin | pointers to examples would be welcome | 14:37 |
| * SteveA runs and hides | 14:37 | |
| mgedmin | I would even accept links to documentation ;) | 14:41 |
| SteveA | there are some interfaces in Persistent or ZODB somewhere | 14:45 |
| *** alga has quit IRC | 14:49 | |
| *** niemeyer has joined #zope3-dev | 14:54 | |
| *** ignas_ has joined #zope3-dev | 14:59 | |
| *** mgedmin has quit IRC | 15:10 | |
| *** mkerrin has joined #zope3-dev | 15:23 | |
| *** viyyer has quit IRC | 15:38 | |
| *** vlado has joined #zope3-dev | 15:40 | |
| *** srichter has joined #zope3-dev | 15:43 | |
| *** ChanServ sets mode: +o srichter | 15:43 | |
| *** alga has joined #zope3-dev | 15:48 | |
| *** BjornT has joined #zope3-dev | 15:50 | |
| *** stub has quit IRC | 15:57 | |
| *** GaryPoster has joined #zope3-dev | 16:00 | |
| *** SteveA_ has joined #zope3-dev | 16:09 | |
| *** SteveA has quit IRC | 16:12 | |
| *** SureshZ has joined #zope3-dev | 16:14 | |
| *** ignas has quit IRC | 16:23 | |
| *** ignas_ is now known as ignas | 16:23 | |
| *** ignas_ has joined #zope3-dev | 16:23 | |
| *** philiKON has quit IRC | 16:27 | |
| *** J1m has joined #zope3-dev | 16:31 | |
| *** mgedmin has joined #zope3-dev | 16:36 | |
| mgedmin | ++skin++Boston is CSS-less for me | 16:39 |
| mgedmin | I think the empty script tag confuses my Firefox | 16:39 |
| mgedmin | <script type="text/javascript" src="http://localhost:8080/++skin++Boston/@@/boston.js" /> | 16:39 |
| mgedmin | yes, changing /> to ></script> fixed it | 16:40 |
| mgedmin | wow, nice | 16:40 |
| mgedmin | projekt01, kudos! | 16:42 |
| mgedmin | the online help window is a little bit too small -- horizontal scrollball appears whenever there is a code or zpt example | 16:43 |
| mgedmin | the whole skin feels somewhat windows-xp-ish, which is a minus to a hardcore linux geek like me, but never mind that | 16:44 |
| mgedmin | we can add themes later ;) | 16:44 |
| *** benji_york has joined #zope3-dev | 16:47 | |
| projekt01 | mgedmin, Ok, thanks for bugfix the skin | 16:55 |
| projekt01 | Hm, feel free to change the width in the online help | 16:57 |
| *** hdima has quit IRC | 16:57 | |
| SteveA_ | J1m: a while ago, I asked you about having an attribute in the zcml page directive to say about a method to call on the view's class before rendering the template. | 17:03 |
| SteveA_ | iirc, you had some more general idea about that, which needed some more thought | 17:03 |
| J1m | Yes | 17:04 |
| J1m | I'll promise to get *something* out by the end of next week | 17:04 |
| * mgedmin overrides view.__call__(), does whatever is necessary before rendering, then does 'return self.index()' | 17:04 | |
| J1m | That works. I'd like to provide something easier and more general | 17:05 |
| J1m | If possible | 17:05 |
| SteveA_ | a pre-rendering subscriber? ;-) | 17:05 |
| J1m | Frankly, I don't have time to think about this right now. | 17:05 |
| *** tvon has joined #zope3-dev | 17:06 | |
| J1m | I'd be happy to schedule a brainstorming session some time if you'd like. | 17:06 |
| SteveA_ | sure, when's good for you? | 17:15 |
| *** tvon|x31 has joined #zope3-dev | 17:16 | |
| *** oferw has joined #zope3-dev | 17:33 | |
| *** tvon has quit IRC | 17:37 | |
| *** `anthony has quit IRC | 17:42 | |
| *** `anthony has joined #zope3-dev | 17:42 | |
| J1m | How about Friday morning (my time) | 17:46 |
| *** htd has quit IRC | 17:46 | |
| SteveA_ | J1m: sure. that works for me. | 17:47 |
| J1m | How about 10am my time (4pm your time?) | 17:48 |
| SteveA_ | what's the time for you right now? | 17:49 |
| J1m | 10:49am | 17:49 |
| SteveA_ | it is 17:49 here | 17:49 |
| SteveA_ | so, 10am will be 5pm my time | 17:50 |
| SteveA_ | works for me | 17:50 |
| J1m | ah, cool | 17:50 |
| J1m | ok | 17:50 |
| *** alga has quit IRC | 17:57 | |
| *** vlado__ has joined #zope3-dev | 18:03 | |
| *** vlado has quit IRC | 18:09 | |
| *** sashav has joined #zope3-dev | 18:10 | |
| *** SureshZ has quit IRC | 18:12 | |
| *** SureshZ has joined #zope3-dev | 18:14 | |
| *** tvon has joined #zope3-dev | 18:25 | |
| *** bskahan has joined #zope3-dev | 18:32 | |
| *** SteveA__ has joined #zope3-dev | 18:33 | |
| *** SteveA__ has quit IRC | 18:34 | |
| *** SteveA has joined #zope3-dev | 18:35 | |
| *** tvon_ has joined #zope3-dev | 18:38 | |
| *** mgedmin has quit IRC | 18:39 | |
| *** tvon|x31 has quit IRC | 18:42 | |
| *** __gotcha has quit IRC | 18:46 | |
| *** SteveA_ has quit IRC | 18:57 | |
| *** tvon has quit IRC | 18:57 | |
| *** bradb has quit IRC | 19:03 | |
| *** mgedmin has joined #zope3-dev | 19:03 | |
| *** BjornT has quit IRC | 19:04 | |
| *** tvon_ is now known as tvon | 19:06 | |
| *** ChanServ sets mode: +o hazmat | 19:16 | |
| *** SteveA has quit IRC | 19:19 | |
| *** deo has joined #zope3-dev | 19:19 | |
| *** oferw has quit IRC | 19:25 | |
| *** SureshZ has quit IRC | 19:26 | |
| *** MalcolmC has quit IRC | 19:44 | |
| *** vlado__ has quit IRC | 20:01 | |
| *** sashav has quit IRC | 20:02 | |
| *** mkerrin has quit IRC | 20:06 | |
| *** Theuni has quit IRC | 20:07 | |
| *** Theuni has joined #zope3-dev | 20:11 | |
| *** SteveA has joined #zope3-dev | 20:15 | |
| *** gintas has joined #zope3-dev | 20:29 | |
| *** jdz_ has joined #zope3-dev | 20:36 | |
| *** bradb has joined #zope3-dev | 20:37 | |
| *** philiKON has joined #zope3-dev | 20:42 | |
| *** gintas has quit IRC | 20:47 | |
| *** hazmat has quit IRC | 20:57 | |
| *** hazmat has joined #zope3-dev | 21:20 | |
| * mgedmin wonders if apidoc can show him the interface inheritance tree of object copied/added/renamed/moved/whatevered events | 21:27 | |
| *** BjornT has joined #zope3-dev | 21:29 | |
| *** tvon has quit IRC | 21:35 | |
| *** alga has joined #zope3-dev | 21:42 | |
| *** hazmat has quit IRC | 21:57 | |
| *** tvon has joined #zope3-dev | 22:06 | |
| *** philiKON has quit IRC | 22:07 | |
| srichter | mgedmin: what do you mean? | 22:08 |
| srichter | like: IObjectEvent -> IEvent -> Interface? | 22:08 |
| srichter | I have thought about this before, but I had not been convinced of its usefullness | 22:09 |
| mgedmin | I'm not sure what I mean | 22:12 |
| mgedmin | I'd like to see at least to all interfaces that extend the one I'm looking at | 22:12 |
| mgedmin | unless there are too many | 22:13 |
| mgedmin | like an interface lists all known classes that implementit | 22:14 |
| mgedmin | or a class lists its known subclasses (it does, doesn't it?) | 22:14 |
| srichter | no, only th edirect ones | 22:24 |
| srichter | so it really does only the first level but not the tree | 22:25 |
| srichter | mgedmin: so I guess I should design this tree at some point, eh? | 22:26 |
| *** hazmat has joined #zope3-dev | 22:26 | |
| mgedmin | first level would be enough | 22:29 |
| mgedmin | tree and graphviz-generated diagrams are optional extras | 22:30 |
| mgedmin | ;) | 22:30 |
| *** bskahan has quit IRC | 22:32 | |
| srichter | the first level is already shown | 22:37 |
| srichter | so you can go to the event interface you are interested in and look at its bases | 22:37 |
| srichter | so you can go to IObjectModifiedEvent | 22:37 |
| mgedmin | oh | 22:38 |
| srichter | and there you will see that one base is IObjectEvent | 22:38 |
| mgedmin | I was looking at an older Zope 3 instance then | 22:38 |
| srichter | you can click on that and you will see IEvent as base | 22:38 |
| mgedmin | wait -- I want to go to IObjectEvent | 22:38 |
| srichter | mmh, that was in 3.0 already as far as I remember | 22:38 |
| mgedmin | and see the first level of subinterfaces | 22:38 |
| mgedmin | that is, IObjectCreatedEvent, IObjectMovedEvent and IObjectModifiedEvent | 22:39 |
| srichter | oh, see you want to see a list of interfaces that extend IObjectEvent | 22:39 |
| mgedmin | yes | 22:39 |
| srichter | oh ok, I have not done that yet, but it should not be that hard actually | 22:39 |
| *** bskahan has joined #zope3-dev | 22:39 | |
| *** BjornT has quit IRC | 22:59 | |
| *** BjornT has joined #zope3-dev | 22:59 | |
| *** BjornT has quit IRC | 23:46 | |
| *** BjornT has joined #zope3-dev | 23:46 | |
| *** deo is now known as deo|food | 23:49 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!