IRC log of #zope3-dev for Tuesday, 2005-02-08

*** srichter has quit IRC00:16
*** srichter has joined #zope3-dev00:52
*** alga has joined #zope3-dev01:15
J1msrichter, ayt?01:42
*** alga_ has joined #zope3-dev01:48
*** alga has quit IRC01:48
*** J1m has quit IRC02:17
*** alienoid has quit IRC03:13
*** hazmat_ has joined #zope3-dev03:19
*** omegadan has joined #zope3-dev03:20
*** hazmat has quit IRC03:22
*** d2m has quit IRC03:23
*** lodragan has joined #zope3-dev03:25
*** omegadan has quit IRC03:28
*** `anthony has quit IRC05:17
*** tav|offl1ne has joined #zope3-dev05:23
*** tav|offline has quit IRC05:23
*** alga_ has quit IRC05:26
*** hazmat_ has quit IRC06:14
*** hazmat_ has joined #zope3-dev06:44
*** `anthony has joined #zope3-dev06:50
*** povbot` has joined #zope3-dev07:27
*** povbot has quit IRC07:27
*** sashav_ has quit IRC07:32
*** apauley has joined #zope3-dev07:55
*** hazmat_ is now known as hazmat08:08
*** ChanServ sets mode: +o hazmat08:08
*** sashav has joined #zope3-dev08:51
*** SteveA has joined #zope3-dev08:53
*** SteveA has joined #zope3-dev08:54
*** d2m has joined #zope3-dev08:56
*** zagy has joined #zope3-dev09:24
*** `anthony has quit IRC09:32
*** Aiste has quit IRC09:35
*** bskahan has quit IRC09:53
*** Aiste has joined #zope3-dev09:54
*** stub has joined #zope3-dev10:24
*** Aiste has quit IRC10:24
*** hazmat has quit IRC10:28
*** Theuni has joined #zope3-dev10:28
*** Aiste has joined #zope3-dev10:55
*** jhauser has joined #zope3-dev11:24
*** MalcolmC has joined #zope3-dev12:01
*** sashav_ has joined #zope3-dev12:12
*** Aiste has quit IRC12:14
*** Aiste has joined #zope3-dev12:19
*** vlado has joined #zope3-dev12:48
*** sashav has quit IRC13:13
*** `anthony has joined #zope3-dev13:35
VladDracusing zope3 stuff standalone is actually pretty easy... I just wonder if I'm doing things the right way :)13:42
philiKONhehe13:48
*** J1m has joined #zope3-dev13:51
VladDracit also provides me with quite alot of insight13:51
VladDracenough insight to say: writing your own zcml directives is cool :)13:51
*** regebro has joined #zope3-dev14:00
*** dc\off has joined #zope3-dev14:41
*** J1m has quit IRC14:44
*** d2m has quit IRC14:56
*** srichter has quit IRC14:57
regebroHmmm.... I have a leeeteeel problem I need to brainstorm....15:00
regebroI'm making a calendar.15:01
regebroEvery event in the calendar needs to have it's own workflow state (invidet(/rejected/accepted)15:01
regebroSo, I'm thinking, every calendar stores it's events as proxies to the real event, which are stored in a separate storage.15:02
regebroThis is good, because it ties in well with the other need: Having separate storages, so we can connect to different calendar servers (exchange, Kolab, that sort of thing).15:02
regebroSo far, so good.15:03
regebroBut, since the storage might not be persistent to Zope, how the heck do I adapt the "real" event to my proxy event?15:03
regebroPlease read this and ask me questions, because I'm stuch in a mode of thinking that doesn't work and that I can't get out from! :)15:04
VladDracI'm not really seeing the problem15:04
VladDracyou somehow have a handle to the 'remote' event15:05
VladDraci.e. a filesystem file, so whenever your objects methods are invoked you access the file15:05
regebroYes, but of course, the evet-proxy object does not know how to access the file. So, I need an adapter that adapts between the file and IEvent, basically.15:07
regebroHmmm.... That adapter can be created when I create the proxy, but it does not have to store the handle to the real event object...15:07
VladDracso you'd need a IRemoteEvent interface and different implementations for different storages, and adapt IRemoveEvent to IEvent (which might be actually no adaption at all)15:08
VladDracyou might need some custom zcml to configure your removeevent15:09
regebroYeah, right. So that could solve the problem, by the adapter knowing what to do.15:09
regebroIf the real object is a ZODB object, I can simply store a reference to that object directly. ... or can I?15:10
jhauserwhy not use a publisher for the events?15:10
regebropublisger?15:10
jhauserthe event has some form of id15:10
regebroyup.15:10
jhausera publisher knows how to create an event object from the id15:11
jhauserthis object can then be adapted15:11
jhauseri use publisher for all access to repositories or stores15:11
regebroThat sounds intriguing.15:11
jhauserso I can use one store with different application specific publishers15:12
regebroI know nothing about publishers...15:12
jhauserits not a special software but an idea15:13
jhauserwe implement publisher as global utilities15:13
regebroI think my main problem now is how to get hold of the real object transparently without having to look it up for each attribute access.15:13
jhauserso the view can call the publisher, get the object and do things with it15:13
regebroWell, I'm obviously going to have some sort of calendar utility/service where you call getEvent(event_id) to get the object. That is not a problem.15:14
regebroI just don't want to do that 5 times every request.15:15
regebro_v_ helps a bit.15:15
jhauserin z2 you could perhaps use a ram cache for this15:16
regebroYeah, maybe. Well, I should be able to start off with just using _v_realobject and checking that it really exists before I do something.15:17
jhauseror the store can implement a cache15:17
jhauserbut then you bind the object to some persistent object, which always needs to be present15:18
regebroYeah, but I still have to (since this is Five) traverse to the store and ask for it every time, in that case...15:18
regebroI think the stores need a cache anyway, for that matter, if it'sexternal to the ZODB.15:18
jhauserah you can store it in the view or not?15:19
regebroWell, I was thinking of keeping the view out of this completely. ;)15:20
regebroAnd let the proxy object handle it transparently.15:20
jhauserhaha ok, but the normal behaviour of a view is to store a context15:20
regebroYeah, you are right. And that would solve things, but I'm not sure how to do that.15:21
regebroHmm, I can experiment a bit.15:21
regebroLet the view create the adapter between the proxy and the real object, and use that as a context. I haven├Ąt fiddled with views that much.15:22
regebroI'll take a look at it. Thanks!15:22
regebroMeh! Makes it hard to unit test... ;)15:23
jhauseryes, that's true15:23
jhauseror at least I haven't learned it yet15:24
*** srichter has joined #zope3-dev15:33
*** ChanServ sets mode: +o srichter15:34
*** Voblia has joined #zope3-dev15:57
apauleysrichter: hi16:05
apauleyI've just done step 1 of adding a content object16:06
apauleyI'm impressed with how much work Zope does for free in generating a view16:07
apauleyanyway, I have to run16:08
*** apauley has quit IRC16:09
regebrojhauser, VladDrac: Well, that solves it I thing. The proxy now stores nothing that the id if the real event.16:12
regebroEvery time you then need to actually ACCESS it, you get a multiadapter between the proxy and the storage.16:12
jhausernice16:13
regebroWhich in turn returns an even that will do what ever is needed. Now I'm gonna see how this works in a real context. ;)16:13
regebroI suspect the view will need to do something tricky too, as I need to pretend that I'm actually working on the proxy (to geth absolute:urls correct and such).16:13
jhauserhm, this starts to smell16:15
*** mgedmin has joined #zope3-dev16:15
jhauserwhy have absolute_url generated by the object16:15
regebroYeah, but much less than it did 30 minutes ago. :P16:15
jhauserhaha16:15
regebroBecause it's the proxy object that generates absolute_url...16:16
regebroWhen you view the object, you want the crumbtrail to show path/to/my/calendar/event16:16
jhauserfrom my external view I would think of a calendar as an application you call on some context, probably a site or a group16:16
regebronot /portal_calendar/storage/6787668276816:16
* mgedmin is interested in calendaring16:17
*** lodragan has left #zope3-dev16:17
regebrojhauser "call on"?16:17
*** vlado_ has joined #zope3-dev16:17
regebroI don't really understand what you mean with that...16:17
jhauseryou start with a persistent place, site, groupfolder or such16:17
jhauserfor this you want to have a calendar16:18
regebroYup.16:18
jhauserthis is an application16:18
*** vlado has quit IRC16:18
jhauserso from there the application should overtake the path handling16:18
jhausereverything after the /path/calendar should be handled by calendar and not some magic traversal16:18
regebroWell, that's all easy to *say* "overtake the path  handling". Much less easy to do. I don't think Zope traversal is especially magic...16:19
jhauserso calendar has a traverser_before_publish where it can intercept the url traversal and take over16:19
jhauserI mean the event object does not need to know the absolute_url and such16:20
jhauserthat's my point16:20
regebroWhy? Every event needs to be have an object stored under calendar anyhow, so there is nothing to take over.16:20
regebrofoo/calendar/anevent will by standards zope traversale return the "anevent" object under calendar. No need for any magick traversal.16:21
*** alga has joined #zope3-dev16:21
jhauserbut you do it differently, because you store the events somewhere else to reuse them16:21
regebroAh, yes. And no.16:21
jhauserin different calendars16:21
regebroEvery different calendar that has an event, will have a proxy event stored in the calendar. There is no magic traversal involved.16:22
regebroThis is needed, because every calendar needs it's own event instance, so it can have it's own workflow state.16:22
jhauserright16:23
regebroThe tricky part here is, that when I open this proxy event for editing, any attribute defined in the Interface, should be proxied.16:24
regebroTo the real event.16:24
regebroNothing else should.16:24
mgedmindef __getattr__(self, name):16:25
mgedmin    if name in IFoo:16:25
regebromgedmin: Yup, that's what I use.16:25
mgedmin        return getattr(self._realobject, name)16:25
regebroThe question is how to knit everything together using adapters. I'm half way there.16:26
SteveApersonally, i construct a class using descriptors16:26
regebroWhich means: My unit tests works. ;) But now I'm gonna make it work in views as well.16:26
SteveAfor doing this16:26
SteveAi have a decorates(IBar) syntax16:26
SteveAfor adapters that decorate16:27
jhauserthis does currently not work with five and zope216:27
VladDracblah.. I'm trying to load zcml in two stages (one stage to setup a basic system, one to do application specific stuff).. doesn't work to well :(16:28
regebroBut it's an interesting idea.16:28
VladDracstuff registered in the first stage gets lost in the second (with context=None), can't figure out what an appropriate context would be16:28
*** tvon has quit IRC16:40
VladDracguess I'll have to read the configuration in a single run then :(16:47
SteveAuse an override for the app-specific parts, perhaps?16:49
VladDracyou mean overrides.zcml?16:52
*** J1m has joined #zope3-dev16:52
VladDracnever mind, this is just not working16:52
SteveAone way is using overrides.zcml16:53
VladDracnow getUtility can't find my utility anymore.. probably more context related stuff that I don't understand16:53
VladDracsteve: I'm trying to use zcml etc outside zope3 - I have to start the zcml machinery myself, so no default 'zope3 behavious' such as overrides.zcml16:54
VladDracI was hoping to make a separate package that would do some simple initailization and then use that from my application and have it load additional, 'local' configuration16:54
VladDracbut I can't get it to work16:54
philiKONSteveA, what does your decorates(IFoo) do?16:59
SteveAi can write an adapter:17:00
SteveAclass AdaptIFooToIBar:17:00
SteveA    implements(IBar)17:00
SteveA    decorates(IFoo)17:00
philiKONah, so it's like adapts()?17:00
philiKONah, wait, i think i get it17:00
SteveA    def methodToOverrideOfIFoo(self):17:01
philiKONit's a decorator also, eh?17:01
SteveA      # do it differently17:01
SteveAin this example, IBar extends IFoo17:01
philiKONso, it's like subclassing, but on an interface/adapter level17:01
SteveAthe decorates(IFoo) makes any names not claimed by the class implementation into descriptors that pass through to the context of the adapter17:01
philiKONyeah, neat17:02
SteveAi'll see about releasing this code17:02
SteveAi don't think it will be a problem17:02
philiKONthat'd be cool17:02
philiKONnot that it's particularly sophisticated17:03
SteveAit isn't, but it has nice tests etc.17:03
philiKONright17:03
philiKONwhy duplicate the work17:03
*** tvon has joined #zope3-dev17:16
*** dc\off has quit IRC17:19
*** bskahan has joined #zope3-dev17:23
*** dc\off has joined #zope3-dev17:24
VladDrac    raise ComponentLookupError("Could not adapt %r to"17:29
VladDraczope.configuration.config.ConfigurationExecutionError: zope.component.exceptions.ComponentLookupError: 'Could not adapt <zope.configuration.config.ConfigurationMachine object at 0x4022646c> to IServiceService'17:29
* VladDrac sobs17:29
*** mkerrin has joined #zope3-dev17:36
*** sashav_ has quit IRC17:37
*** Theuni has quit IRC17:54
*** dc\off is now known as dreamcatcher17:57
*** kinder has joined #zope3-dev18:07
VladDracok18:26
VladDracI give up18:26
VladDraczope3 cannot be used standalone by (relative) newbies18:26
VladDrac(unfortunate because it would be a cool way to learn more)18:27
*** vlado__ has joined #zope3-dev18:27
Damascenewhat's the problem?18:27
Damasceneactually, i am a newbie as well, so i doubt i could help!  :)18:27
philiKONVladDrac, say, what's the problem18:30
philiKONthis shouldn't be too hard18:30
philiKONwhat do you need to do?18:30
VladDracI want to use utilities, adapters, interfaces, zcml outside of zope, basically18:31
VladDracafaik, zope3 can do most registrations/parsing using some sort of global state18:32
VladDracbut strangely enough my lookups fail18:32
*** vlado_ has quit IRC18:35
philiKONhave you looked at Five?18:38
VladDracI have18:41
philiKONis it something else you need?18:41
*** vlado__ has quit IRC18:41
VladDracsorry my head hurts - gotta stop this z3 thing now - brb :)18:42
*** vlado__ has joined #zope3-dev18:42
philiKONok :)18:43
*** tziade has joined #zope3-dev18:43
tziadedreamcatcher: hi18:44
dreamcatcherhi18:44
tziadedreamcatcher: small Five question18:44
tziadewhy is BrowserView based on Acquisition.Explicit ?18:44
philiKONtziade, for permission purposes18:45
tziadeit gives us problems (efge@nuxeo speaking here)18:45
dreamcatcherto be able to evaluate security settings, otherwise the user folder where your user is defined wouldnt be reachable18:45
philiKONotherwise views won't be able to inherit a zope2 security context18:45
dreamcatcherit gives me problems too, we need to fix that eventually18:45
tziadehm...18:45
philiKONtziade, what kind of problems?18:45
philiKONtziade, because you want to use new-style stuff?18:45
tziadepb is that view.context is then weirdly wrapped18:45
dreamcatcherphiliKON: acquisition problems18:46
philiKONtziade, well, yes, acquisition wrapped18:46
tziadeI don't find the original aq-wrapping of the context18:46
dreamcatcheryou get [<context>, <view>, <context>, <container>, <container-parent> ...]18:46
dreamcatcherin aq_chain18:46
tziadeyes18:46
tziadeok I see the reasons, I'll try to work around the aq_chain  in my code18:48
tziadethx18:48
dreamcatcherif you eventually find a better fix, let us know18:48
tziadeok will do18:49
*** kinder has quit IRC18:49
*** vlado__ has quit IRC18:57
*** vlado has joined #zope3-dev18:58
tziadeok the pb was in my tests, I added view = view.__of__(context) after creating it and before using it18:59
*** Fosten has joined #zope3-dev19:03
tziadeok the pb was in my tests, I added view = view.__of__(context) after creating it and before using it19:04
tziadebye all19:05
*** tziade has left #zope3-dev19:05
*** vlado has quit IRC19:07
*** vlado has joined #zope3-dev19:08
*** alga has quit IRC19:16
*** alga has joined #zope3-dev19:16
*** dreamcatcher has quit IRC19:33
*** regebro has quit IRC19:34
*** Fosten has left #zope3-dev19:40
*** MalcolmC has quit IRC19:41
*** alga has quit IRC19:41
*** vlado has quit IRC19:44
*** mkerrin has left #zope3-dev19:47
*** mexiKON has joined #zope3-dev19:49
*** philiKON has quit IRC20:10
*** hazmat has joined #zope3-dev20:11
*** dreamcatcher has joined #zope3-dev20:13
*** mexiKON is now known as philiKON20:20
*** d2m has joined #zope3-dev20:31
*** alga has joined #zope3-dev20:39
*** dreamcatcher has quit IRC21:12
*** dreamcatcher has joined #zope3-dev21:14
*** dreamcatcher has left #zope3-dev21:16
*** jhauser_ has joined #zope3-dev21:30
*** jhauser has quit IRC21:40
*** tvon has quit IRC21:44
*** SteveA has quit IRC22:00
*** stub has quit IRC22:20
*** tvon has joined #zope3-dev22:38
*** hazmat has quit IRC23:09
*** hazmat has joined #zope3-dev23:13
*** hazmat is now known as haz-food23:14
*** tvon has quit IRC23:31
*** upsidedown has joined #zope3-dev23:31
*** upsidedown has left #zope3-dev23:38
* mgedmin has a problem23:44
mgedminI had a Data.fs that used zope.app.pau23:44
mgedminI went to ++etc++site, unregistered the principal folder and LocalPAU, removed the registrations, removed the component23:45
mgedminthen I upgraded Zope 323:45
mgedminthen I went to ++etc++site, added LocalPluggableAuthentication and PrincipalFolder23:45
mgedminbut when I try to register the principal folder, I get a system error23:45
mgedminCan't pickle <class 'zope.app.pau.interfaces.ISearchableAuthenticationPlugin'>: import of module zope.app.pau.interfaces failed23:46
mgedminI do not understand where zope.app.pau comes from23:46
mgedminrecursive grep through the sources reveals that the only occurence of 'zope.app.pau' is in Data.fs23:46
mgedmin(in an old transaction, I assume)23:46
mgedminfield.interface in the request is zope.app.authentication.interfaces.ISearchableAuthenticationPlugin, according to the error log23:47
* mgedmin is stumped23:47
J1mI fear you have an entry for it in your utility service.23:50
* J1m starts zope to investigate ...23:51
J1mmgedmin, what happens if you go to your local utilities service?23:53
*** haz-food is now known as hazmat23:53
*** ChanServ sets mode: +o hazmat23:53
J1mmgedmin, ayt?23:54
mgedminJ1m, I do not see it in the local utilities service23:55
mgedminbesides, I removed the old PrincipalFolder, and zope3 wouldn't allow me to do that if it were used, would it?23:55
J1mI can't see your local utilities service, so, no I can't23:55
mgedminthat's why I had to explicitly unregister the registrations, then explicitly remove the registrations23:55
J1mAre you looking at:23:55
J1mhttp://localhost:8080/++etc++site/default/Utilities/@@utilities.html23:56
mgedminand only then I could actually remove the principal folder and LocalPAU utility23:56
J1m?23:56
* mgedmin nods23:56
mgedminI see five utilities there23:56
J1mDo you see an entry for the principal folder?23:56
mgedminerror reporting, principal annotation, authentication (the one I just added), cliend id manager, session data container23:56
mgedminthat's all23:56
mgedminno principal folders23:56
mgedminneither there are any in /++etc++site/default/RegistrationManager/@@index.html23:57
J1mI think you'll have to delete and recreate your utilities service.23:57
J1mI think there is probably an empty entry in the utilities service containing a registration stack for the missing interafce.23:58
J1mI think there is probably an empty entry in the utilities service containing a registration stack for the missing interaface.23:58
J1mI think there is probably an empty entry in the utilities service containing a registration stack for the missing interface.23:58
mgedminI have a backup of the Data.fs23:59
J1mThe good news is that I think Stephan's work will do away with registration stacks23:59
mgedminand I also have a copy of the old Zope3 tree23:59
mgedminwould I see that entry in the utilities service if I looked with the old Zope?23:59
mgedminperhaps I could remove it then?23:59

Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!