IRC log of #zope3-dev for Sunday, 2006-04-23

*** tarek has joined #zope3-dev00:04
*** efrerich_ has quit IRC00:12
*** mgedmin has quit IRC00:21
*** jachin has joined #zope3-dev00:27
jachinhi there00:27
jachinI'm trying to figure out zope3's security system00:28
jachinI'm working through the zope book and so far everything seems pretty clear00:28
jachinthe one thing that doesn't seem obvious to me though is how to give permission to an object that belongs to someone00:29
jachini.e. take the message board example00:29
jachinhow would I give a user the ability to edit only the messages they created00:30
jachin?00:30
jachinDo I have to do something with the meta-data/DC?00:30
jachinIs there a good example that someone knows of that could show me the zope way to do that sort of thing?00:31
*** projekt01 has joined #zope3-dev00:38
projekt01good night00:38
projekt01somebody with formlib error handling expirience ot there?00:39
*** strichter has joined #zope3-dev01:01
projekt01Hi Stephan01:03
*** strichter is now known as srichter01:07
*** ChanServ sets mode: +o srichter01:07
projekt01srichter, the formlib don't catches ValidationError. Is this correct?01:08
projekt01btw, hi srichter01:08
srichterit should01:16
srichterI am pretty sure it does, actually01:16
*** pcardune has joined #zope3-dev01:17
srichterok, I am about to go to bed01:17
srichterprojekt01: I'll talk to you later01:17
*** srichter has quit IRC01:18
*** ignas has quit IRC01:21
*** jachin has quit IRC02:09
*** dunny has joined #zope3-dev02:20
*** tarek has quit IRC02:46
*** yota has quit IRC03:23
*** projekt01 has left #zope3-dev04:41
*** pcardune has quit IRC05:43
*** vinsci has quit IRC06:23
*** pcardune has joined #zope3-dev06:34
*** philiMAC has joined #zope3-dev08:30
*** stub has joined #zope3-dev08:44
*** yota has joined #zope3-dev08:45
*** mexiKON has quit IRC08:48
*** stub has quit IRC10:14
*** natea has quit IRC10:22
*** dobee has joined #zope3-dev10:27
*** rockyburt has quit IRC10:54
*** dobee has quit IRC10:57
*** d2m has quit IRC11:04
*** dunny has quit IRC11:12
*** vinsci has joined #zope3-dev11:32
*** dunny has joined #zope3-dev11:35
*** dobee has joined #zope3-dev11:50
*** tarek has joined #zope3-dev12:46
*** philiMAC has quit IRC12:47
*** romanofski has joined #zope3-dev13:17
romanofskimoin13:17
*** rockyburt has joined #zope3-dev13:25
*** d2m has joined #zope3-dev13:27
*** BjornT has quit IRC13:55
*** MJ has quit IRC14:00
*** BjornT has joined #zope3-dev14:03
*** BjornT has quit IRC14:06
*** BjornT has joined #zope3-dev14:08
*** philiKON has joined #zope3-dev14:09
*** SiggyF has joined #zope3-dev14:10
*** dobee has quit IRC14:28
*** tarek has quit IRC14:29
*** dunny has quit IRC14:51
*** ignas has joined #zope3-dev15:21
*** alecm has joined #zope3-dev15:28
*** alecm has quit IRC15:46
*** roym has joined #zope3-dev15:56
roymI'm having difficulty with ztapi.subscribe to only report when a16:01
roymparticular type of object is added.16:01
roym16:01
roym# handleMyEvent never gets called with this type of registration16:01
roym#ztapi.subscribe([IObjectAddedEvent], MyInterface, handleMyEvent)16:01
roym16:01
roym# This works, but I need to manually filter tje object16:01
roymztapi.subscribe([IObjectAddedEvent], None, handleMyEvent)16:02
roym16:02
roymdef handleMyEvent(*args):16:02
roym  print "args are:", args16:02
roym  return16:02
roymAll the examples that I can find in the source code always seem to use None as the 2nd argument.16:02
roym(to the ztapi.subscribe call, that is).16:03
philiKONroym, forget ztapi :)16:03
roymbut its just a thin wrapper, isn't it16:04
philiKONzope.component.provideHandler16:04
philiKONz.c.provideHandler(my_event_subscriber, (IObjectAddedEvent,))16:04
roymah. thanks - let me look at that.16:04
roymso there is no way to discriminate based on the object type (as ztapi.subscribe promises) in the registration?16:05
philiKONz.c.provideHandler(my_event_subscriber, (IObjectAddedEvent, IMyObjectType))16:06
philiKONor perhaps it's the other way around16:06
philiKONnever remember :)16:06
roymlovely - thats what I need.16:06
*** stub has joined #zope3-dev16:17
*** J1m has joined #zope3-dev16:20
*** alecm has joined #zope3-dev16:47
*** drzoltron_ has joined #zope3-dev17:22
drzoltron_anyone around who participated in the NeckarSprint, oct. 05 ?17:24
*** dobee has joined #zope3-dev17:34
*** jinty has joined #zope3-dev17:43
*** efrerich has joined #zope3-dev17:54
*** stub has quit IRC18:02
*** alecm has quit IRC18:02
*** jinty has quit IRC18:15
*** drzoltron_ has quit IRC18:18
*** drzoltron_ has joined #zope3-dev18:31
*** drzoltron_ has quit IRC18:40
*** hazmat has quit IRC18:43
J1mphiliKON, ayt?18:57
*** hazmat has joined #zope3-dev19:06
*** hazmat has quit IRC19:06
*** hazmat has joined #zope3-dev19:07
*** regebro has joined #zope3-dev19:09
*** natea has joined #zope3-dev19:13
philiKONJ1m, now i am19:16
philiKONwhat's up19:16
J1mdid you deprecate layers?19:16
philiKONsort of. yes19:17
philiKONi see your checkin now19:17
J1mk :)19:17
*** natea_ has joined #zope3-dev19:17
philiKONi'll respond19:17
J1mk19:17
*** natea has quit IRC19:21
J1mYay! No more deprecation warnings on my branch.19:44
J1mI deserve a break.19:44
regebroHooray for J1m!19:55
regebrophiliKON: When you in your compromise write from "zope.publisher.browser import BrowserPage" what do you mean? :)19:56
regebroMy Zope 3.2 doesn't have that class...19:56
philiKONzope 3.3 will :)19:56
philiKONJ1m, yay19:56
philiKONregebro, currently it's known as zope.formlib.Page19:56
philiKONregebro, see the README.txt of the zope3.2 compatible version of zope.browserzcml219:56
regebroOK, cool, thanks.19:57
philiKONregebro, zope.publisher.browser.BrowserPage is on jim-adapter branch19:57
regebroWell, if it does the same as zope.formlib.page, it's fine. because then I understand your example. :)19:58
*** jukart has joined #zope3-dev20:03
philiKONregebro, :)20:07
*** tarek has joined #zope3-dev20:11
*** jukart has quit IRC20:51
*** pcardune has quit IRC20:59
*** ignas has quit IRC21:15
*** romanofski has quit IRC21:45
*** ignas has joined #zope3-dev21:46
*** natea_ has quit IRC22:01
regebroWell... OK...22:07
regebroI now have a small and rather ugly implementation of a page directive.22:08
regebroIt creates no magic temporary classes.22:08
regebroAnd it allows you to have many pages per view class.22:09
philiKONregebro, can i see it?22:09
philiKONdoes it use browserDefault?22:09
regebroSure. Where do you want me to put it?22:09
philiKONregebro, email?22:09
philiKONor paste it somewhere?22:09
regebroYup, it switches pages in browser default depending on what you were looking for.22:09
regebroI'll tar it and mail it to you.22:10
philiKONregebro, i had this idea originally too22:10
regebroRight, is there a hidden problem with it? I haven't tested it very well. :)22:11
philiKONno. i'm curious about your implementation22:11
philiKONi'll say more when i've had a look22:11
philiKONin particular, i'm curious if you had the same idea as i had22:12
philiKONand SteveA, even22:12
philiKONbecause in that case it might be time for that idea ;)22:12
regebroWell, if I had the same idea as you and it works, I'll say that I'm a genius. :)22:17
regebroOK, sent.22:17
philiKONgot it22:17
regebroIt has the friendly name hello:page. Because I built it in my hello world product. :)22:18
philiKONi don't like the dynamic template22:20
philiKONif they know they need a template, they can put it on the class22:20
philiKONit's just another callable attr22:20
*** ignas has quit IRC22:20
regebroYeah I thought about that.22:20
philiKONregebro, wanna hear my/SteveA's idea?22:21
regebroI'm not religiously attached to that part.22:21
regebroSure.22:21
philiKONclass MultiplePages(BrowserPages): # notice plural22:22
philiKON    @publish('foo.html')22:22
philiKON    def foo(self):22:22
philiKON        return u'Foo'22:22
philiKON    bar = publish(ViewPageTemplateFile('bar.pt'))22:22
philiKONuh, that wouldn't work22:22
philiKON    bar = publish('bar')(ViewPageTemplateFile('bar.pt')22:23
philiKONor something like that22:23
philiKONand then you'd also just do <browser2:page factory=".MultiplePages" name="foo.html" /> and <browser2:page factory=".MultiplePages" name="bar.html" />22:23
regebroOK.22:23
philiKONwhat does @publish do?22:23
philiKONit sets the dispatch table22:24
philiKONwhat you call class._pages i think22:24
regebroAh.22:24
philiKONto the outside, MultiplePages behaves like a standard page. outside meaning the browser2:page directive22:24
regebroYeah, OK, I kinda like having the naming in zcml.22:24
philiKONi agree22:24
philiKONwhich is why it's just an idea, not a proposal ;)22:25
regebroSo instead of publish, we'd set the dispatch table in zcml, and then it's pretty much the same idea as mine.22:25
regebro(and _pages is ugly fo course, it should have a proper api).22:26
philiKONi'm not sure if i like modifying the class from zcml22:26
philiKONit has a monkey patch sort of feeling to it22:26
philiKONideally, i would like pages to be registerable with zope.comopnent.provideAdapter22:26
J1mespecially since a class might be used for multiple views.22:27
philiKONyep22:27
regebroWell, my code handles that, but currently without checks. ;)22:27
regebroBut you are right, a real registry would be nice.22:28
regebroBut can an adpater be just a method?22:28
philiKONan adapter is a whole object22:28
* J1m isn't really paying attention22:28
philiKONregebro, see, the point is this22:29
* J1m is getting nervous seeing a reference to a registry22:29
philiKONheh :)22:29
philiKONs/registry/dispatch table/22:29
* philiKON wonders if that made things worse22:29
philiKONregebro, anyways. when we write adapters, we write one class per adapter, right?22:29
regebroWith registry I mean "not just a mokeypatched dict". :)22:29
regebrophiliKON: Yup.22:30
philiKONregebro, why can't we do that when we write pages? one page, one class.22:30
J1mphiliKON, btw, sort of22:30
J1mI'm not happy about the dependence of zope.component.zcml on zope.security22:30
regebroBecause you end up having loads of class that do nothing ecept act as placeholders.22:30
philiKONJ1m, me neither22:30
philiKONregebro, well, that remains to be seen22:31
philiKONregebro, i haven't really tested browser2:page and this paradigm on a lot of code yet22:31
philiKONi'm not so sure that we'll create loads and loads of classes22:31
J1mwe should consider moving that out.22:31
philiKONJ1m, ok.22:31
philiKONJ1m, were should be move it out then. the whole adapter directive (i think utility also) depends on protecting factories22:32
regebroWell, I'll end up with loads of class YetAnoteherClass(MyViewclass): __call__ = PageTemplateFile("yetanotherpagetemplate.pt")22:33
J1mI don't know.  Let me think about it some more.22:33
philiKONregebro, for that you can use browser2:pageTemplate22:33
philiKONregebro, ah wait22:33
philiKONregebro, now i get it22:33
J1mwhy do we need a directive that allows multiple pages on the same view?22:33
philiKONthe base class22:33
regebroJ1m because I want it. :)22:33
J1mwhy?22:33
philiKONJ1m, regebro argues to avoit repeating creating lots of classes22:34
philiKONavoid22:34
J1mI don't understand22:34
regebroBecause thats what I end up with.22:34
philiKONJ1m, say you have a set of page templates22:34
philiKONJ1m, they all need auxiliary methods from a view class22:34
philiKONJ1m, so far you'd put everything on one class22:34
regebroI have a class (say Event) and I need loads of pages on that class.22:34
philiKONthe methods, the page templates22:34
philiKONetc.22:34
philiKONand register each template with the class individually as a browser:page22:35
philiKONwithout being able to register several pages from one class, you'd have to create a class for each one22:35
philiKONyou might be able to put the commonly needed auxiliary methods on a base class22:35
J1mThat's insane22:35
philiKONbut you'll still have to create lots of classes22:35
J1m1. You can use the same class for multiple pages22:35
philiKONwe're not talking about now, we're talking about browser2:page22:36
J1m2. You can use the browser:pages grouping directive to avoid having to repeat the class.22:36
philiKONyes, yes, i know22:36
philiKONwe're talking about directives that won't create classes on the fly22:37
regebroYes, but how to do it if we kill browser:page and browser:pages?22:37
philiKONbrowser:page and browser:pages create classes on the fly22:37
*** MJ has joined #zope3-dev22:37
philiKONbrowser2:page doesn't take a 'template' parameter22:37
philiKONit just takes a 'factory' parameter and registers this as an adapter22:37
philiKONthe 'factory' has to implement zope.formlib.interfaces.IPage22:37
philiKONhttp://www.zope.org/DevHome/Wikis/DevSite/Projects/ComponentArchitecture/TheBrowserPageCompromise22:38
regebroWell, at this point, U have a compromise compromise. :) We deprecate browser:page(s) and I create a product which I call "hello" which contains supportclasses and directives to easily create contentclasses and pages, with a little bit of magic. :)22:39
regebros/U/I22:40
J1mso the question is, are you going to create something better? Or just different.22:40
regebroAnybody who gets miffed that creating pages is a pain can use hello. :)22:40
J1mIt looks like the latter.22:40
philiKONJ1m, are you talking about my proposal?22:40
J1myes22:41
philiKONas for browser2:pageTemplate and browser2:page, i'd say the former22:41
J1mYou are still creating classes on the fly.22:41
philiKONonly browser2:pagesFromClass22:41
philiKONit's part of that compromise22:41
philiKONfor all icare, i wouldn't have it22:41
philiKONbut people like regebro invariably want it22:41
philiKONbrowser2:pageTemplate and browser2:page are excessively stupid.22:42
regebroI think its just different, as I mentioned on the list. It moves complexity around, but doesn't remove it.22:42
J1malso browser2:pageTemplate22:42
philiKONJ1m, ok, true22:42
philiKONJ1m, but it's very very stupid about that22:42
philiKONbrowser2:pageTemplate is also a compromise :)22:42
J1mI really don't think this is worth the bother.22:43
philiKONtoo late: http://svn.zope.org/zope.browserzcml2/trunk/src/zope/browserzcml2/ :)22:43
J1mYeah yeah22:43
philiKONmy main motivator is browser2:page22:43
J1mBTW, I'll share a recent experience.22:44
J1mI had been away from z3 for a while.22:44
J1mI had to do a new registration UI.22:44
J1mMy needs were quire simple.22:44
J1mMy needs were quite simple.22:44
J1mzope.formlib.Page gave me almost everything I needed.22:45
J1mI could do all of my registrations via <adapter>22:45
philiKONgreat. browser2:page is the perfect companion for it :)22:45
J1mEven the security worked well.22:45
philiKONright22:45
J1mI don't need browser anything.22:46
J1mJust adapter22:46
philiKONso, the question is,s hould we encourage to teach people about registering zope.formlib.Page pages with <adapter />22:46
philiKON?22:46
J1mI'm not done. :)22:46
philiKONoh, sorry22:46
philiKONplease continue22:46
J1mThe only thing that stopped me was the lack of menu support.22:46
J1mThe one thing that browser:page gave me that I didn't have was a way to define a menu item.22:47
philiKON<brower:menuItem />22:47
philiKON?22:47
J1mI could have used a browser:menuitem. but we sort of want to get rid of that too.22:48
J1myes22:48
J1mso I just sucked it up and used browser:page.22:48
philiKONah. how are we getting rid of it?22:48
J1mI thought we were.22:48
philiKON(btw, browser2:page does <adapter /> + menu)22:48
philiKONhttp://svn.zope.org/zope.browserzcml2/trunk/src/zope/browserzcml2/zcml.py?rev=67267&view=auto22:48
philiKONgrep for "def page"22:49
regebroWell, you two slug it out. :) I think I'm a genius anyway, and that my hello-thingy is a better path forward than dynamic classes.22:49
philiKONregebro, :)22:50
regebroI reserve the right to change my mind on this. :)22:50
J1mso for me, the only reason to use page is to get the menu defined.22:50
J1mOtherwise, I'd definately prefer adapter.22:50
J1mend of story :)22:50
regebroYeah, well the hello-thingy is adapter + some traversal.22:50
regebro(and menu, althugh I ahven't tested that).22:51
regebroNow my gf wants to see a movie, so I'm gonna go. See ya tomorrow or something.22:51
philiKONbye22:52
*** regebro has quit IRC22:53
*** dobee has quit IRC22:53
*** efrerich_ has joined #zope3-dev22:57
*** efrerich has quit IRC23:15
*** efrerich_ is now known as efrerich23:23
roymMy understanding of the containerViews directive is that, for an object O, it produces 3 views (action.html, index.html and +). These are views on O. How would I make the adding view of the parent have a choice to add the object O.23:23
*** MJ has quit IRC23:23
*** dunny has joined #zope3-dev23:25
roymI guess what I am asking is could I tell addMenuItem to use the "+" view of object O.23:28
*** SiggyF has quit IRC23:33
*** projekt01 has joined #zope3-dev23:36
roymnever mind - I think I see that you have to use both addform and containerViews, and then reference the addform view from addMenuItem. Can someone please confirm that this is right.23:37
projekt01roym, yup23:42
*** MJ has joined #zope3-dev23:50
*** efrerich has quit IRC23:54
roymprojekt01: thanks.23:58

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