| *** C8N has left #zope3-dev | 00:03 | |
| VladDrac | damn | 00:16 |
|---|---|---|
| VladDrac | schoolbell is really nice! | 00:16 |
| *** SureshZ has left #zope3-dev | 00:43 | |
| *** jhauser has quit IRC | 00:46 | |
| *** bradb is now known as bradb-away | 01:14 | |
| *** oferw has joined #zope3-dev | 01:25 | |
| *** timte has quit IRC | 01:27 | |
| *** benji_york has quit IRC | 01:41 | |
| *** J1m has quit IRC | 01:47 | |
| *** oferw has quit IRC | 01:57 | |
| *** MiUlEr has joined #zope3-dev | 02:25 | |
| *** projekt01 has quit IRC | 03:08 | |
| *** yota has quit IRC | 03:14 | |
| *** MiUlEr has quit IRC | 03:23 | |
| *** bradb-away is now known as bradb | 03:28 | |
| *** andrew_ has quit IRC | 03:40 | |
| *** andrew_ has joined #zope3-dev | 03:41 | |
| *** stub has joined #zope3-dev | 03:46 | |
| *** tav has joined #zope3-dev | 03:47 | |
| *** ChanServ sets mode: +o tav | 03:47 | |
| tav | hmzie | 03:47 |
| *** SureshZ has joined #zope3-dev | 04:07 | |
| *** tav has quit IRC | 05:07 | |
| *** RaFromBRC has quit IRC | 05:38 | |
| *** bradb is now known as bradb-away | 05:38 | |
| *** MiUlEr has joined #zope3-dev | 06:44 | |
| *** MiUlEr has quit IRC | 06:58 | |
| *** SureshZ has quit IRC | 07:00 | |
| *** tvon has quit IRC | 07:05 | |
| *** zagy has joined #zope3-dev | 09:27 | |
| *** sashav has joined #zope3-dev | 09:57 | |
| *** mexiKON has quit IRC | 10:01 | |
| *** bradb-away has quit IRC | 10:15 | |
| *** bradb-away has joined #zope3-dev | 10:19 | |
| *** hdima has joined #zope3-dev | 10:22 | |
| *** projekt01 has joined #zope3-dev | 10:38 | |
| *** VladDrac has quit IRC | 10:44 | |
| *** VladDrac has joined #zope3-dev | 10:46 | |
| *** d2m has quit IRC | 11:47 | |
| *** scottles has joined #zope3-dev | 11:52 | |
| *** regebro has joined #zope3-dev | 11:54 | |
| *** d2m has joined #zope3-dev | 12:01 | |
| *** jhauser has joined #zope3-dev | 12:10 | |
| *** palmTree has joined #zope3-dev | 12:14 | |
| VladDrac | too bad schoolbell still has these tiny interface issues that make it sometimes unpleasant to work with | 12:16 |
| VladDrac | hmm you might want to turn on your tv and watch some news, esp if you're in london | 12:36 |
| scottles | yeah.. a bus has apparently exploded too now.. | 12:37 |
| scottles | im reading the bbc news website | 12:37 |
| Theuni | wtf? | 12:43 |
| VladDrac | http://www.sky.com/skynews/article/0,,30000-1188265,00.html | 12:44 |
| *** Aiste has joined #zope3-dev | 13:01 | |
| *** philiKON has joined #zope3-dev | 13:04 | |
| sashav | anyone here have opinions about PEAK? | 13:06 |
| *** philiKON has quit IRC | 13:07 | |
| *** J1m has joined #zope3-dev | 13:12 | |
| *** lunatik has joined #zope3-dev | 13:13 | |
| *** philiKON has joined #zope3-dev | 13:17 | |
| *** lunatik has left #zope3-dev | 13:19 | |
| *** palmTree has quit IRC | 13:27 | |
| *** jhauser has quit IRC | 13:53 | |
| *** philiKON has quit IRC | 14:13 | |
| *** J1m has quit IRC | 14:17 | |
| *** faassen has joined #zope3-dev | 14:24 | |
| *** ignas has joined #zope3-dev | 14:27 | |
| *** andrew_ is now known as andrew_m | 14:45 | |
| *** MiUlEr has joined #zope3-dev | 14:48 | |
| *** mgedmin has joined #zope3-dev | 14:49 | |
| *** j-w has joined #zope3-dev | 14:50 | |
| faassen | anybody has any idea how an object can quite suddenly lose its __parent__ and __name__? | 14:50 |
| faassen | i.e. it's there at one step, but then when a method is called on this object, suddenly they vanish. | 14:50 |
| srichter | that can only happen if the object uses location proxies for storing names and parents | 14:53 |
| faassen | how does an object end up using location proxies? | 14:53 |
| srichter | Make sure that you object provides IContained or even better inherits Contained | 14:53 |
| srichter | if it does nto provide IContained | 14:54 |
| faassen | hmm.. | 14:55 |
| faassen | thanks, that sounds likely. | 14:55 |
| MiUlEr | hi | 14:55 |
| faassen | because this really screws up the catalog too. | 14:55 |
| faassen | i.e. an object isn't itself anymore. :) | 14:55 |
| faassen | as you have one that's a location proxy,I guess, and the other that isn't. | 14:56 |
| faassen | perhaps better to have the location proxies not happen so automagically. | 14:56 |
| faassen | as it seems to confuse the catalog? | 14:56 |
| faassen | i..e an object that loses its locationproxy doesn't seem to be recognized by the IIntId utility. | 14:56 |
| faassen | even though it's there under another guise. | 14:56 |
| srichter | mmh, maybe we need to change the catalog implementation? | 14:58 |
| faassen | well, the problem is that the unwrapped objects just don't appear to have an int id. | 14:58 |
| faassen | I think perhaps the proxies have a PersistentKeyreference or whatnot. | 14:59 |
| srichter | or IntId utility | 14:59 |
| faassen | and since there's only a reference to the proxied object, the unproxied object cannot be recognized. | 14:59 |
| faassen | not sure how you could alter the catalog or int id utility to understand this. | 14:59 |
| faassen | unless int id makes sure to always keep a reference to the unproxied object. | 14:59 |
| faassen | but you wouldn't want that either. | 14:59 |
| faassen | as then you would get an object without parent, etc. | 15:00 |
| srichter | I have not looked at the code at all, so I cannot comment. | 15:00 |
| *** bradb-away is now known as bradb | 15:00 | |
| faassen | I'll post to the zope3-dev list. | 15:00 |
| srichter | I guess we have to wait for Jim | 15:00 |
| srichter | yeah | 15:00 |
| efge | hm 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 |
| faassen | efge: well, that'd suck too. | 15:18 |
| faassen | efge: as then the objects retrieved from the catalog wouldn't know their location. | 15:18 |
| faassen | efge: unless the int id facility kept track of both. | 15:19 |
| efge | hm yeh | 15:19 |
| efge | I haven't completely wrapped my mind around these things :/ | 15:19 |
| faassen | efge: basically I am suggesting LocationProxy stuff is evil. | 15:19 |
| faassen | efge: I'm just starting to do this today, and I'm sure I'm not there yet. | 15:19 |
| faassen | efge: you're pretty fast to pick this up in 5 seconds from a few irc messages, I took hours. :) | 15:19 |
| efge | faassen: well I've been looking at that code in the past ;) | 15:20 |
| j-w | faassen: 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 |
| efge | when are objects forcibly location-proxied ? | 15:21 |
| efge | when they're stored in a container, right ? | 15:21 |
| faassen | efge: I guess so. | 15:22 |
| faassen | efge: I haven't explored that yet. | 15:22 |
| efge | faassen: yeah I remember now | 15:22 |
| efge | if the added object doesn't adapt to ILocation, then it's proxied | 15:23 |
| VladDrac | efge: I think upon traversal | 15:23 |
| efge | so that we can stick a __name__ and __parent__ on it | 15:23 |
| efge | and then on, from the catalog & friend's point of view, it's the proxy that counts | 15:24 |
| efge | that's done so you can add "dump" python objects to containers | 15:24 |
| faassen | VladDrac: 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 |
| efge | s/dump/dumb | 15:24 |
| faassen | efge: right, but the problem with that is that the unique id facility gets unreliable, in combination with the catalog. | 15:25 |
| efge | faassen: how exactly ? | 15:25 |
| faassen | efge: as if you send the modified event from one of the object's methods, you're passing along the unproxied object. | 15:25 |
| efge | ah right | 15:25 |
| faassen | efge: and then the catalog will try to look up the unproxied object's id. but doesn't find one. | 15:25 |
| faassen | efge: and then everything fails. | 15:25 |
| VladDrac | faassen ah ok | 15:25 |
| faassen | efge: of course if you really had a dumb python object, it wouldn't ever do this. | 15:25 |
| faassen | efge: 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 |
| efge | faassen: meaning, you'd better implement ILocation yourself :) | 15:26 |
| faassen | efge: yes, but it's rather surprising at first, don't you think? | 15:26 |
| faassen | efge: as this problem *doesn't* occur if you send the event from some other code, for instance the views. | 15:27 |
| faassen | efge: so it was really mysterious in the good old traditional Zope 2 way. | 15:27 |
| efge | faassen: agreed, but I guess that's part of "playing nice with the framework" | 15:27 |
| efge | the standard advice is "inherit from Persistent and Contained" | 15:27 |
| faassen | efge: okay, well, that this was really required was news to me. | 15:27 |
| faassen | efge: and mysterious failures if you don't aren't ideal. | 15:28 |
| faassen | efge: but I can't think easily of a better tradeoff. anyway, onwards. :) | 15:28 |
| * SteveA is ideologically opposed to containment | 15:59 | |
| j-w | SteveA, can you elaborate on that a little? | 16:03 |
| faassen | SteveA: you mean containment of communism? | 16:03 |
| SteveA | zope3 has, kind of by accident, acquired an unhealthy dependency on __parent__ and __name__ | 16:03 |
| SteveA | this was introduced for two reasons | 16:04 |
| SteveA | - to get rid of ContextWrapper, allowing for local services | 16:04 |
| faassen | SteveA: 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 models | 16:04 |
| SteveA | i don't think those role / permissions models should be "core" enough to make everyone pay the price of supporting __parent__ and __name__ | 16:05 |
| SteveA | and with the thread-local interaction context, there is no need for it to allow for local services | 16:05 |
| *** philiKON has joined #zope3-dev | 16:05 | |
| faassen | SteveA: but isn't it nice to also know where your object is when you get it from, say, the catalog? | 16:07 |
| SteveA | what does "where your object is" mean, exactly? | 16:07 |
| SteveA | so, we have URLs and IAbsoluteURL to express where in the URL hierarchy something is | 16:07 |
| faassen | SteveA: okay, ask for the url could be one example. another one would be to check which folder it's in, perhaps? | 16:07 |
| SteveA | there should be ITraversalPath for the "tales path url" to something | 16:08 |
| SteveA | neither of these should *depend on* __parent__ or __name__ | 16:08 |
| SteveA | if you need that feature, provide it in an adapter suitable to your system | 16:08 |
| SteveA | i have such things in launchpad, for example, which are specific to the launchpad arrangement of things. | 16:08 |
| SteveA | i don't think there's a generic way to do it that does't impose expensive infrastructure on everything | 16:09 |
| SteveA | by all means, have a system for this, but keep it an optional add-on | 16:09 |
| faassen | SteveA: well, it is better than proxies. I'd almost suggest getting rid of LocationProxy, or at least it automatically kicking in. | 16:09 |
| SteveA | maybe an ECM thing | 16:09 |
| SteveA | i agree that it is better than proxies. i think not having it at all is even better. | 16:10 |
| philiKON | not having what? | 16:10 |
| faassen | SteveA: right, so actuall getting rid of location proxies would get you a long way already. | 16:10 |
| SteveA | philiKON: you came in too late. read the logs. | 16:11 |
| faassen | SteveA: 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 |
| philiKON | ah right, the logs | 16:11 |
| * philiKON reads | 16:11 | |
| SteveA | and now, after stiring things up a bit, i must go to lunch. | 16:11 |
| j-w | bon appetti | 16:11 |
| faassen | SteveA: okay, I will also proceed on making forms now. | 16:11 |
| SteveA | lunch is tastier and more nutritious | 16:12 |
| *** bradb is now known as bradb-brb | 16:12 | |
| *** SureshZ has joined #zope3-dev | 16:24 | |
| efge | interesting view about __name__ and __parent__, I think I nearly agree | 16:32 |
| efge | containment is an artefact of the application, not so much of the framework | 16:33 |
| *** bradb-brb is now known as bradb | 16:47 | |
| *** bradb has quit IRC | 16:55 | |
| *** bradb has joined #zope3-dev | 16:55 | |
| *** benji_york has joined #zope3-dev | 17:02 | |
| *** bob2 has joined #zope3-dev | 17:20 | |
| bob2 | does anything depend on adapters storing the adaptee in self.context? | 17:20 |
| philiKON | no | 17:21 |
| *** hdima has quit IRC | 17:22 | |
| bob2 | excellent, thanks | 17:22 |
| philiKON | it's just a convention we often follow | 17:22 |
| philiKON | especially with views | 17:22 |
| bob2 | oh, your book arrived last week, it's quite good :) | 17:22 |
| philiKON | but you can't rely on it being there, for example when you do IFoo(obj) and obj already provides IFoo... | 17:22 |
| philiKON | glad you like it | 17:23 |
| philiKON | feedback is always welcome | 17:23 |
| *** elbixio has joined #zope3-dev | 17:27 | |
| *** stub has quit IRC | 17:45 | |
| *** elbixio has quit IRC | 17:54 | |
| *** tvon has joined #zope3-dev | 18:09 | |
| SteveA | bob2: the answer is "sometimes". There is an interface like IContextDependent or something | 18:17 |
| SteveA | that the adapter object is meant to provide when we're depending on this | 18:17 |
| SteveA | the context being right is important for views in launchpad for example | 18:17 |
| SteveA | and views are a particular kind of adapter | 18:17 |
| *** faassen has left #zope3-dev | 18:18 | |
| *** faassen has joined #zope3-dev | 18:18 | |
| *** sashav has quit IRC | 18:20 | |
| *** j-w has quit IRC | 18:20 | |
| VladDrac | I'm trying to store interfaces in the catalog (fieldindex) - does that make sense? | 18:58 |
| VladDrac | I guess I'll need to unproxy them first for it to work at all | 18:58 |
| faassen | VladDrac: I guess it's possible to store them..they're supposed to be immutable and I guess they're sortable too.. | 18:58 |
| faassen | VladDrac: of course there's already some optimized interface storage thingy inside Zope 3 itself, though non-persistent.. | 18:59 |
| *** tvon has quit IRC | 18:59 | |
| VladDrac | it's more consistent for me to store them in the catalog | 19:00 |
| philiKON | interfaces aren't immutable | 19:00 |
| *** J1m has joined #zope3-dev | 19:00 | |
| faassen | philiKON: when aren't they? | 19:00 |
| *** tvon has joined #zope3-dev | 19:00 | |
| philiKON | when? | 19:00 |
| faassen | philiKON: when do they get mutated? | 19:01 |
| philiKON | when you mess with them | 19:01 |
| VladDrac | hmm, well, if I unwrap() the intefaces, it seems to work | 19:01 |
| faassen | philiKON: well, when do you mess with them? | 19:01 |
| philiKON | dunno | 19:01 |
| philiKON | i'm just saying | 19:01 |
| philiKON | they're not immutable | 19:01 |
| philiKON | they *can* be mutated | 19:01 |
| faassen | philiKON: I mean, i'm talking about philosophically immutable, obviously almost no class instance in Python is actually immutable. | 19:01 |
| philiKON | you can be immutable if you're written in C | 19:02 |
| faassen | philiKON: sure, but you can store philosophically immutable things as BTrees keys. | 19:02 |
| VladDrac | basically, the content type of my objects is defined by the ICubicContent derived interface they implement | 19:02 |
| philiKON | even from a philosophically point of view: | 19:02 |
| philiKON | IInterface.setTaggedValue | 19:02 |
| VladDrac | I think it would be clean to index the appropriate interface (i.e. IDocument, INews) as the type of the object | 19:02 |
| philiKON | VladDrac, requiring people to derive from interfaces sucks... why not make ICubicContent an interface type? | 19:02 |
| faassen | philiKON: 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 |
| philiKON | true | 19:03 |
| VladDrac | phil: I'm gonna do some re-reading on interfaces before I comment on that :) | 19:04 |
| philiKON | VladDrac, chapter 5 intro in my book | 19:09 |
| philiKON | basically, ICubicContent could extend IContentType | 19:09 |
| J1m | faassen, I responded to your email | 19:15 |
| J1m | I'll be back in an hour or so if you want to discuss. | 19:16 |
| *** J1m is now known as J1m|away | 19:16 | |
| *** MiUlEr has quit IRC | 19:19 | |
| efge | generating events from views could work, yeah | 19:20 |
| *** tvon has quit IRC | 19:28 | |
| * Theuni notices that one can lock himself out of a zope3 instance when removing products and objects are still around | 19:29 | |
| Theuni | s/products/packages/ | 19:29 |
| philiKON | good boy :() | 19:29 |
| philiKON | Theuni, z3 does have broken object support | 19:30 |
| Theuni | yeah. and it tells me that i don't have enough rights on those ... | 19:31 |
| Theuni | actually I removed the package-includes but the code is still around | 19:31 |
| Theuni | so i shouldn't wonder maybe ... did so in the first place anyway | 19:32 |
| SteveA | well, you could use a different security policy | 19:32 |
| SteveA | that failed to "you have permission" | 19:32 |
| Theuni | :) | 19:32 |
| SteveA | rather than one that fails to "you have no permission" | 19:32 |
| *** scottles has quit IRC | 19:42 | |
| *** philiKON has quit IRC | 20:03 | |
| *** philiKON has joined #zope3-dev | 20:04 | |
| *** efge has quit IRC | 20:07 | |
| VladDrac | philikon I now see why I inherit from ICubicContent - it's because ICubicContent defines some basic attributes | 20:20 |
| VladDrac | and my browser:addform depends on one of these attributes | 20:21 |
| VladDrac | ZopeXMLConfigurationError: File "/home/ivo/Projects/Zope3/instances/z3-cubic/lib/python/cubic/types/browser/configure.zcml", line 22.4-29.10 | 20:21 |
| VladDrac | ValueError: ('Some set_before_add are not included in the form', [u'title']) | 20:21 |
| *** bradb is now known as bradb-lunch | 20:24 | |
| VladDrac | guess some interface baseclass is unavoidable | 20:26 |
| philiKON | so you're requiring every piece of content in your cms to provide this interface and thus have those attributes... hmmm | 20:27 |
| VladDrac | at this moment, all content is required to provide a title attribute, so the INameChooser can generate an id from it | 20:30 |
| VladDrac | I could refactor that into a separate interface, make it independend of ICubicContent | 20: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-bank | 20:40 | |
| *** faassen has quit IRC | 20:41 | |
| *** J1m|away is now known as J1m | 20:51 | |
| *** regebro has quit IRC | 20:57 | |
| *** ignas has quit IRC | 21:51 | |
| *** RaFromBRC has joined #zope3-dev | 21:52 | |
| *** mgedmin has quit IRC | 22:10 | |
| *** AJC has joined #zope3-dev | 22:32 | |
| *** bradb-bank is now known as bradb | 22:51 | |
| *** bcsaller has joined #zope3-dev | 23:13 | |
| *** lunati1 has joined #zope3-dev | 23:33 | |
| *** jhauser has joined #zope3-dev | 23:36 | |
| *** RaFromBRC is now known as RaFromBRC|afk | 23:42 | |
| *** lunati1 has left #zope3-dev | 23:46 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!