IRC log of #zope3-dev for Thursday, 2005-07-07

*** C8N has left #zope3-dev00:03
VladDracschoolbell is really nice!00:16
*** SureshZ has left #zope3-dev00:43
*** jhauser has quit IRC00:46
*** bradb is now known as bradb-away01:14
*** oferw has joined #zope3-dev01:25
*** timte has quit IRC01:27
*** benji_york has quit IRC01:41
*** J1m has quit IRC01:47
*** oferw has quit IRC01:57
*** MiUlEr has joined #zope3-dev02:25
*** projekt01 has quit IRC03:08
*** yota has quit IRC03:14
*** MiUlEr has quit IRC03:23
*** bradb-away is now known as bradb03:28
*** andrew_ has quit IRC03:40
*** andrew_ has joined #zope3-dev03:41
*** stub has joined #zope3-dev03:46
*** tav has joined #zope3-dev03:47
*** ChanServ sets mode: +o tav03:47
*** SureshZ has joined #zope3-dev04:07
*** tav has quit IRC05:07
*** RaFromBRC has quit IRC05:38
*** bradb is now known as bradb-away05:38
*** MiUlEr has joined #zope3-dev06:44
*** MiUlEr has quit IRC06:58
*** SureshZ has quit IRC07:00
*** tvon has quit IRC07:05
*** zagy has joined #zope3-dev09:27
*** sashav has joined #zope3-dev09:57
*** mexiKON has quit IRC10:01
*** bradb-away has quit IRC10:15
*** bradb-away has joined #zope3-dev10:19
*** hdima has joined #zope3-dev10:22
*** projekt01 has joined #zope3-dev10:38
*** VladDrac has quit IRC10:44
*** VladDrac has joined #zope3-dev10:46
*** d2m has quit IRC11:47
*** scottles has joined #zope3-dev11:52
*** regebro has joined #zope3-dev11:54
*** d2m has joined #zope3-dev12:01
*** jhauser has joined #zope3-dev12:10
*** palmTree has joined #zope3-dev12:14
VladDractoo bad schoolbell still has these tiny interface issues that make it sometimes unpleasant to work with12:16
VladDrachmm you might want to turn on your tv and watch some news, esp if you're in london12:36
scottlesyeah.. a bus has apparently exploded too now..12:37
scottlesim reading the bbc news website12:37
*** Aiste has joined #zope3-dev13:01
*** philiKON has joined #zope3-dev13:04
sashavanyone here have opinions about PEAK?13:06
*** philiKON has quit IRC13:07
*** J1m has joined #zope3-dev13:12
*** lunatik has joined #zope3-dev13:13
*** philiKON has joined #zope3-dev13:17
*** lunatik has left #zope3-dev13:19
*** palmTree has quit IRC13:27
*** jhauser has quit IRC13:53
*** philiKON has quit IRC14:13
*** J1m has quit IRC14:17
*** faassen has joined #zope3-dev14:24
*** ignas has joined #zope3-dev14:27
*** andrew_ is now known as andrew_m14:45
*** MiUlEr has joined #zope3-dev14:48
*** mgedmin has joined #zope3-dev14:49
*** j-w has joined #zope3-dev14:50
faassenanybody has any idea how an object can quite suddenly lose its __parent__ and __name__?14:50
faasseni.e. it's there at one step, but then when a method is called on this object, suddenly they vanish.14:50
srichterthat can only happen if the object uses location proxies for storing names and parents14:53
faassenhow does an object end up using location proxies?14:53
srichterMake sure that you object provides IContained or even better inherits Contained14:53
srichterif it does nto provide IContained14:54
faassenthanks, that sounds likely.14:55
faassenbecause this really screws up the catalog too.14:55
faasseni.e. an object isn't itself anymore. :)14:55
faassenas you have one that's a location proxy,I guess, and the other that isn't.14:56
faassenperhaps better to have the location proxies not happen so automagically.14:56
faassenas it seems to confuse the catalog?14:56
faasseni..e an object that loses its locationproxy doesn't seem to be recognized by the IIntId utility.14:56
faasseneven though it's there under another guise.14:56
srichtermmh, maybe we need to change the catalog implementation?14:58
faassenwell, the problem is that the unwrapped objects just don't appear to have an int id.14:58
faassenI think perhaps the proxies have a PersistentKeyreference or whatnot.14:59
srichteror IntId utility14:59
faassenand since there's only a reference to the proxied object, the unproxied object cannot be recognized.14:59
faassennot sure how you could alter the catalog or int id utility to understand this.14:59
faassenunless int id makes sure to always keep a reference to the unproxied object.14:59
faassenbut you wouldn't want that either.14:59
faassenas then you would get an object without parent, etc.15:00
srichterI have not looked at the code at all, so I cannot comment.15:00
*** bradb-away is now known as bradb15:00
faassenI'll post to the zope3-dev list.15:00
srichterI guess we have to wait for Jim15:00
efgehm so you're suggesting that PersistentKeyReference should recognize location proxied objects, and keep a reference to the underlying object instead of the proxy ?15:18
faassenefge: well, that'd suck too.15:18
faassenefge: as then the objects retrieved from the catalog wouldn't know their location.15:18
faassenefge: unless the int id facility kept track of both.15:19
efgehm yeh15:19
efgeI haven't completely wrapped my mind around these things :/15:19
faassenefge: basically I am suggesting LocationProxy stuff is evil.15:19
faassenefge: I'm just starting to do this today, and I'm sure I'm not there yet.15:19
faassenefge: you're pretty fast to pick this up in 5 seconds from a few irc messages, I took hours. :)15:19
efgefaassen: well I've been looking at that code in the past ;)15:20
j-wfaassen: they are not supposed to know their location, right? Since this will happen for objects that do not implement IContained anyway.15:20
j-w(or maybe I miss something here)15:21
efgewhen are objects forcibly location-proxied ?15:21
efgewhen they're stored in a container, right ?15:21
faassenefge: I guess so.15:22
faassenefge: I haven't explored that yet.15:22
efgefaassen: yeah I remember now15:22
efgeif the added object doesn't adapt to ILocation, then it's proxied15:23
VladDracefge: I think upon traversal15:23
efgeso that we can stick a __name__ and __parent__ on it15:23
efgeand then on, from the catalog & friend's point of view, it's the proxy that counts15:24
efgethat's done so you can add "dump" python objects to containers15:24
faassenVladDrac: I think that's Zope 2 acquisition does that, but not Zope 3, I think it must be the folder, as these proxies are persistently stored.15:24
faassenefge: right, but the problem with that is that the unique id facility gets unreliable, in combination with the catalog.15:25
efgefaassen: how exactly ?15:25
faassenefge: as if you send the modified event from one of the object's methods, you're passing along the unproxied object.15:25
efgeah right15:25
faassenefge: and then the catalog will try to look up the unproxied object's id. but doesn't find one.15:25
faassenefge: and then everything fails.15:25
VladDracfaassen ah ok15:25
faassenefge: of course if you really had a dumb python object, it wouldn't ever do this.15:25
faassenefge: but it's a bit of a dead chicken to have to subclass Contained..(and throwing away your objects and creating them again, in case you forgot accidentally)15:26
efgefaassen: meaning, you'd better implement ILocation yourself :)15:26
faassenefge: yes, but it's rather surprising at first, don't you think?15:26
faassenefge: as this problem *doesn't* occur if you send the event from some other code, for instance the views.15:27
faassenefge: so it was really mysterious in the good old traditional Zope 2 way.15:27
efgefaassen: agreed, but I guess that's part of "playing nice with the framework"15:27
efgethe standard advice is "inherit from Persistent and Contained"15:27
faassenefge: okay, well, that this was really required was news to me.15:27
faassenefge: and mysterious failures if you don't aren't ideal.15:28
faassenefge: but I can't think easily of a better tradeoff. anyway, onwards. :)15:28
* SteveA is ideologically opposed to containment15:59
j-w SteveA, can you elaborate on that a little?16:03
faassenSteveA: you mean containment of communism?16:03
SteveAzope3 has, kind of by accident, acquired an unhealthy dependency on __parent__ and __name__16:03
SteveAthis was introduced for two reasons16:04
SteveA - to get rid of ContextWrapper, allowing for local services16:04
faassenSteveA: but we all know wrappers lead to problems. :)16:04
SteveA - to support a simple implementation of absolute urls and certain kinds of role / permission models16:04
SteveAi don't think those role / permissions models should be "core" enough to make everyone pay the price of supporting __parent__ and __name__16:05
SteveAand with the thread-local interaction context, there is no need for it to allow for local services16:05
*** philiKON has joined #zope3-dev16:05
faassenSteveA: but isn't it nice to also know where your object is when you get it from, say, the catalog?16:07
SteveAwhat does "where your object is" mean, exactly?16:07
SteveAso, we have URLs and IAbsoluteURL to express where in the URL hierarchy something is16:07
faassenSteveA: okay, ask for the url could be one example. another one would be to check which folder it's in, perhaps?16:07
SteveAthere should be ITraversalPath for the "tales path url" to something16:08
SteveAneither of these should *depend on* __parent__ or __name__16:08
SteveAif you need that feature, provide it in an adapter suitable to your system16:08
SteveAi have such things in launchpad, for example, which are specific to the launchpad arrangement of things.16:08
SteveAi don't think there's a generic way to do it that does't impose expensive infrastructure on everything16:09
SteveAby all means, have a system for this, but keep it an optional add-on16:09
faassenSteveA: well, it is better than proxies. I'd almost suggest getting rid of LocationProxy, or at least it automatically kicking in.16:09
SteveAmaybe an ECM thing16:09
SteveAi agree that it is better than proxies.  i think not having it at all is even better.16:10
philiKONnot having what?16:10
faassenSteveA: right, so actuall getting rid of location proxies would get you a long way already.16:10
SteveAphiliKON: you came in too late.  read the logs.16:11
faassenSteveA: as then you'd only need to trace down the other parts of the code that turn out to depend on __name__ and __parent__.16:11
philiKONah right, the logs16:11
* philiKON reads16:11
SteveAand now, after stiring things up a bit, i must go to lunch.16:11
j-wbon appetti16:11
faassenSteveA: okay, I will also proceed on making forms now.16:11
SteveAlunch is tastier and more nutritious16:12
*** bradb is now known as bradb-brb16:12
*** SureshZ has joined #zope3-dev16:24
efgeinteresting view about __name__ and __parent__, I think I nearly agree16:32
efgecontainment is an artefact of the application, not so much of the framework16:33
*** bradb-brb is now known as bradb16:47
*** bradb has quit IRC16:55
*** bradb has joined #zope3-dev16:55
*** benji_york has joined #zope3-dev17:02
*** bob2 has joined #zope3-dev17:20
bob2does anything depend on adapters storing the adaptee in self.context?17:20
*** hdima has quit IRC17:22
bob2excellent, thanks17:22
philiKONit's just a convention we often follow17:22
philiKONespecially with views17:22
bob2oh, your book arrived last week, it's quite good :)17:22
philiKONbut you can't rely on it being there, for example when you do IFoo(obj) and obj already provides IFoo...17:22
philiKONglad you like it17:23
philiKONfeedback is always welcome17:23
*** elbixio has joined #zope3-dev17:27
*** stub has quit IRC17:45
*** elbixio has quit IRC17:54
*** tvon has joined #zope3-dev18:09
SteveAbob2: the answer is "sometimes".  There is an interface like IContextDependent or something18:17
SteveAthat the adapter object is meant to provide when we're depending on this18:17
SteveAthe context being right is important for views in launchpad for example18:17
SteveAand views are a particular kind of adapter18:17
*** faassen has left #zope3-dev18:18
*** faassen has joined #zope3-dev18:18
*** sashav has quit IRC18:20
*** j-w has quit IRC18:20
VladDracI'm trying to store interfaces in the catalog (fieldindex) - does that make sense?18:58
VladDracI guess I'll need to unproxy them first for it to work at all18:58
faassenVladDrac: I guess it's possible to store them..they're supposed to be immutable and I guess they're sortable too..18:58
faassenVladDrac: of course there's already some optimized interface storage thingy inside Zope 3 itself, though non-persistent..18:59
*** tvon has quit IRC18:59
VladDracit's more consistent for me to store them in the catalog19:00
philiKONinterfaces aren't immutable19:00
*** J1m has joined #zope3-dev19:00
faassenphiliKON: when aren't they?19:00
*** tvon has joined #zope3-dev19:00
faassenphiliKON: when do they get mutated?19:01
philiKONwhen you mess with them19:01
VladDrachmm, well, if I unwrap() the intefaces, it seems to work19:01
faassenphiliKON: well, when do you mess with them?19:01
philiKONi'm just saying19:01
philiKONthey're not immutable19:01
philiKONthey *can* be mutated19:01
faassenphiliKON: I mean, i'm talking about philosophically immutable, obviously almost no class instance in Python is actually immutable.19:01
philiKONyou can be immutable if you're written in C19:02
faassenphiliKON: sure, but you can store philosophically immutable things as BTrees keys.19:02
VladDracbasically, the content type of my objects is defined by the ICubicContent derived interface they implement19:02
philiKONeven from a philosophically point of view:19:02
VladDracI think it would be clean to index the appropriate interface (i.e. IDocument, INews) as the type of the object19:02
philiKONVladDrac, requiring people to derive from interfaces sucks... why not make ICubicContent an interface type?19:02
faassenphiliKON: right, that might give trouble if they're used as index keys, but they'd still be globally unique and the tagged value wouldn't influence the sorting order, I think, so you might still be safe. :)19:03
VladDracphil: I'm gonna do some re-reading on interfaces before I comment on that :)19:04
philiKONVladDrac, chapter 5 intro in my book19:09
philiKONbasically, ICubicContent could extend IContentType19:09
J1mfaassen, I responded to your email19:15
J1mI'll be back in an hour or so if you want to discuss.19:16
*** J1m is now known as J1m|away19:16
*** MiUlEr has quit IRC19:19
efgegenerating events from views could work, yeah19:20
*** tvon has quit IRC19:28
* Theuni notices that one can lock himself out of a zope3 instance when removing products and objects are still around19:29
philiKONgood boy :()19:29
philiKONTheuni, z3 does have broken object support19:30
Theuniyeah. and it tells me that i don't have enough rights on those ...19:31
Theuniactually I removed the package-includes but the code is still around19:31
Theuniso i shouldn't wonder maybe ... did so in the first place anyway19:32
SteveAwell, you could use a different security policy19:32
SteveAthat failed to "you have permission"19:32
SteveArather than one that fails to "you have no permission"19:32
*** scottles has quit IRC19:42
*** philiKON has quit IRC20:03
*** philiKON has joined #zope3-dev20:04
*** efge has quit IRC20:07
VladDracphilikon I now see why I inherit from ICubicContent - it's because ICubicContent defines some basic attributes20:20
VladDracand my browser:addform depends on one of these attributes20:21
VladDrac ZopeXMLConfigurationError: File "/home/ivo/Projects/Zope3/instances/z3-cubic/lib/python/cubic/types/browser/configure.zcml", line 22.4-29.1020:21
VladDrac    ValueError: ('Some set_before_add are not included in the form', [u'title'])20:21
*** bradb is now known as bradb-lunch20:24
VladDracguess some interface baseclass is unavoidable20:26
philiKONso you're requiring every piece of content in your cms to provide this interface and thus have those attributes... hmmm20:27
VladDracat this moment, all content is required to provide a title attribute, so the INameChooser can generate an id from it20:30
VladDracI could refactor that into a separate interface, make it independend of ICubicContent20:30
VladDrac(but still, my entire schema must be accessible through a single interface, so I'll need to derive from my IGenerateIdfromTitle interface)20:31
*** bradb-lunch is now known as bradb-bank20:40
*** faassen has quit IRC20:41
*** J1m|away is now known as J1m20:51
*** regebro has quit IRC20:57
*** ignas has quit IRC21:51
*** RaFromBRC has joined #zope3-dev21:52
*** mgedmin has quit IRC22:10
*** AJC has joined #zope3-dev22:32
*** bradb-bank is now known as bradb22:51
*** bcsaller has joined #zope3-dev23:13
*** lunati1 has joined #zope3-dev23:33
*** jhauser has joined #zope3-dev23:36
*** RaFromBRC is now known as RaFromBRC|afk23:42
*** lunati1 has left #zope3-dev23:46

Generated by 2.15.1 by Marius Gedminas - find it at!