| *** tarek has joined #zope3-dev | 00:04 | |
| *** efrerich_ has quit IRC | 00:12 | |
| *** mgedmin has quit IRC | 00:21 | |
| *** jachin has joined #zope3-dev | 00:27 | |
| jachin | hi there | 00:27 |
|---|---|---|
| jachin | I'm trying to figure out zope3's security system | 00:28 |
| jachin | I'm working through the zope book and so far everything seems pretty clear | 00:28 |
| jachin | the one thing that doesn't seem obvious to me though is how to give permission to an object that belongs to someone | 00:29 |
| jachin | i.e. take the message board example | 00:29 |
| jachin | how would I give a user the ability to edit only the messages they created | 00:30 |
| jachin | ? | 00:30 |
| jachin | Do I have to do something with the meta-data/DC? | 00:30 |
| jachin | Is 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-dev | 00:38 | |
| projekt01 | good night | 00:38 |
| projekt01 | somebody with formlib error handling expirience ot there? | 00:39 |
| *** strichter has joined #zope3-dev | 01:01 | |
| projekt01 | Hi Stephan | 01:03 |
| *** strichter is now known as srichter | 01:07 | |
| *** ChanServ sets mode: +o srichter | 01:07 | |
| projekt01 | srichter, the formlib don't catches ValidationError. Is this correct? | 01:08 |
| projekt01 | btw, hi srichter | 01:08 |
| srichter | it should | 01:16 |
| srichter | I am pretty sure it does, actually | 01:16 |
| *** pcardune has joined #zope3-dev | 01:17 | |
| srichter | ok, I am about to go to bed | 01:17 |
| srichter | projekt01: I'll talk to you later | 01:17 |
| *** srichter has quit IRC | 01:18 | |
| *** ignas has quit IRC | 01:21 | |
| *** jachin has quit IRC | 02:09 | |
| *** dunny has joined #zope3-dev | 02:20 | |
| *** tarek has quit IRC | 02:46 | |
| *** yota has quit IRC | 03:23 | |
| *** projekt01 has left #zope3-dev | 04:41 | |
| *** pcardune has quit IRC | 05:43 | |
| *** vinsci has quit IRC | 06:23 | |
| *** pcardune has joined #zope3-dev | 06:34 | |
| *** philiMAC has joined #zope3-dev | 08:30 | |
| *** stub has joined #zope3-dev | 08:44 | |
| *** yota has joined #zope3-dev | 08:45 | |
| *** mexiKON has quit IRC | 08:48 | |
| *** stub has quit IRC | 10:14 | |
| *** natea has quit IRC | 10:22 | |
| *** dobee has joined #zope3-dev | 10:27 | |
| *** rockyburt has quit IRC | 10:54 | |
| *** dobee has quit IRC | 10:57 | |
| *** d2m has quit IRC | 11:04 | |
| *** dunny has quit IRC | 11:12 | |
| *** vinsci has joined #zope3-dev | 11:32 | |
| *** dunny has joined #zope3-dev | 11:35 | |
| *** dobee has joined #zope3-dev | 11:50 | |
| *** tarek has joined #zope3-dev | 12:46 | |
| *** philiMAC has quit IRC | 12:47 | |
| *** romanofski has joined #zope3-dev | 13:17 | |
| romanofski | moin | 13:17 |
| *** rockyburt has joined #zope3-dev | 13:25 | |
| *** d2m has joined #zope3-dev | 13:27 | |
| *** BjornT has quit IRC | 13:55 | |
| *** MJ has quit IRC | 14:00 | |
| *** BjornT has joined #zope3-dev | 14:03 | |
| *** BjornT has quit IRC | 14:06 | |
| *** BjornT has joined #zope3-dev | 14:08 | |
| *** philiKON has joined #zope3-dev | 14:09 | |
| *** SiggyF has joined #zope3-dev | 14:10 | |
| *** dobee has quit IRC | 14:28 | |
| *** tarek has quit IRC | 14:29 | |
| *** dunny has quit IRC | 14:51 | |
| *** ignas has joined #zope3-dev | 15:21 | |
| *** alecm has joined #zope3-dev | 15:28 | |
| *** alecm has quit IRC | 15:46 | |
| *** roym has joined #zope3-dev | 15:56 | |
| roym | I'm having difficulty with ztapi.subscribe to only report when a | 16:01 |
| roym | particular type of object is added. | 16:01 |
| roym | 16:01 | |
| roym | # handleMyEvent never gets called with this type of registration | 16:01 |
| roym | #ztapi.subscribe([IObjectAddedEvent], MyInterface, handleMyEvent) | 16:01 |
| roym | 16:01 | |
| roym | # This works, but I need to manually filter tje object | 16:01 |
| roym | ztapi.subscribe([IObjectAddedEvent], None, handleMyEvent) | 16:02 |
| roym | 16:02 | |
| roym | def handleMyEvent(*args): | 16:02 |
| roym | print "args are:", args | 16:02 |
| roym | return | 16:02 |
| roym | All 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 |
| philiKON | roym, forget ztapi :) | 16:03 |
| roym | but its just a thin wrapper, isn't it | 16:04 |
| philiKON | zope.component.provideHandler | 16:04 |
| philiKON | z.c.provideHandler(my_event_subscriber, (IObjectAddedEvent,)) | 16:04 |
| roym | ah. thanks - let me look at that. | 16:04 |
| roym | so there is no way to discriminate based on the object type (as ztapi.subscribe promises) in the registration? | 16:05 |
| philiKON | z.c.provideHandler(my_event_subscriber, (IObjectAddedEvent, IMyObjectType)) | 16:06 |
| philiKON | or perhaps it's the other way around | 16:06 |
| philiKON | never remember :) | 16:06 |
| roym | lovely - thats what I need. | 16:06 |
| *** stub has joined #zope3-dev | 16:17 | |
| *** J1m has joined #zope3-dev | 16:20 | |
| *** alecm has joined #zope3-dev | 16:47 | |
| *** drzoltron_ has joined #zope3-dev | 17:22 | |
| drzoltron_ | anyone around who participated in the NeckarSprint, oct. 05 ? | 17:24 |
| *** dobee has joined #zope3-dev | 17:34 | |
| *** jinty has joined #zope3-dev | 17:43 | |
| *** efrerich has joined #zope3-dev | 17:54 | |
| *** stub has quit IRC | 18:02 | |
| *** alecm has quit IRC | 18:02 | |
| *** jinty has quit IRC | 18:15 | |
| *** drzoltron_ has quit IRC | 18:18 | |
| *** drzoltron_ has joined #zope3-dev | 18:31 | |
| *** drzoltron_ has quit IRC | 18:40 | |
| *** hazmat has quit IRC | 18:43 | |
| J1m | philiKON, ayt? | 18:57 |
| *** hazmat has joined #zope3-dev | 19:06 | |
| *** hazmat has quit IRC | 19:06 | |
| *** hazmat has joined #zope3-dev | 19:07 | |
| *** regebro has joined #zope3-dev | 19:09 | |
| *** natea has joined #zope3-dev | 19:13 | |
| philiKON | J1m, now i am | 19:16 |
| philiKON | what's up | 19:16 |
| J1m | did you deprecate layers? | 19:16 |
| philiKON | sort of. yes | 19:17 |
| philiKON | i see your checkin now | 19:17 |
| J1m | k :) | 19:17 |
| *** natea_ has joined #zope3-dev | 19:17 | |
| philiKON | i'll respond | 19:17 |
| J1m | k | 19:17 |
| *** natea has quit IRC | 19:21 | |
| J1m | Yay! No more deprecation warnings on my branch. | 19:44 |
| J1m | I deserve a break. | 19:44 |
| regebro | Hooray for J1m! | 19:55 |
| regebro | philiKON: When you in your compromise write from "zope.publisher.browser import BrowserPage" what do you mean? :) | 19:56 |
| regebro | My Zope 3.2 doesn't have that class... | 19:56 |
| philiKON | zope 3.3 will :) | 19:56 |
| philiKON | J1m, yay | 19:56 |
| philiKON | regebro, currently it's known as zope.formlib.Page | 19:56 |
| philiKON | regebro, see the README.txt of the zope3.2 compatible version of zope.browserzcml2 | 19:56 |
| regebro | OK, cool, thanks. | 19:57 |
| philiKON | regebro, zope.publisher.browser.BrowserPage is on jim-adapter branch | 19:57 |
| regebro | Well, if it does the same as zope.formlib.page, it's fine. because then I understand your example. :) | 19:58 |
| *** jukart has joined #zope3-dev | 20:03 | |
| philiKON | regebro, :) | 20:07 |
| *** tarek has joined #zope3-dev | 20:11 | |
| *** jukart has quit IRC | 20:51 | |
| *** pcardune has quit IRC | 20:59 | |
| *** ignas has quit IRC | 21:15 | |
| *** romanofski has quit IRC | 21:45 | |
| *** ignas has joined #zope3-dev | 21:46 | |
| *** natea_ has quit IRC | 22:01 | |
| regebro | Well... OK... | 22:07 |
| regebro | I now have a small and rather ugly implementation of a page directive. | 22:08 |
| regebro | It creates no magic temporary classes. | 22:08 |
| regebro | And it allows you to have many pages per view class. | 22:09 |
| philiKON | regebro, can i see it? | 22:09 |
| philiKON | does it use browserDefault? | 22:09 |
| regebro | Sure. Where do you want me to put it? | 22:09 |
| philiKON | regebro, email? | 22:09 |
| philiKON | or paste it somewhere? | 22:09 |
| regebro | Yup, it switches pages in browser default depending on what you were looking for. | 22:09 |
| regebro | I'll tar it and mail it to you. | 22:10 |
| philiKON | regebro, i had this idea originally too | 22:10 |
| regebro | Right, is there a hidden problem with it? I haven't tested it very well. :) | 22:11 |
| philiKON | no. i'm curious about your implementation | 22:11 |
| philiKON | i'll say more when i've had a look | 22:11 |
| philiKON | in particular, i'm curious if you had the same idea as i had | 22:12 |
| philiKON | and SteveA, even | 22:12 |
| philiKON | because in that case it might be time for that idea ;) | 22:12 |
| regebro | Well, if I had the same idea as you and it works, I'll say that I'm a genius. :) | 22:17 |
| regebro | OK, sent. | 22:17 |
| philiKON | got it | 22:17 |
| regebro | It has the friendly name hello:page. Because I built it in my hello world product. :) | 22:18 |
| philiKON | i don't like the dynamic template | 22:20 |
| philiKON | if they know they need a template, they can put it on the class | 22:20 |
| philiKON | it's just another callable attr | 22:20 |
| *** ignas has quit IRC | 22:20 | |
| regebro | Yeah I thought about that. | 22:20 |
| philiKON | regebro, wanna hear my/SteveA's idea? | 22:21 |
| regebro | I'm not religiously attached to that part. | 22:21 |
| regebro | Sure. | 22:21 |
| philiKON | class MultiplePages(BrowserPages): # notice plural | 22: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 |
| philiKON | uh, that wouldn't work | 22:22 |
| philiKON | bar = publish('bar')(ViewPageTemplateFile('bar.pt') | 22:23 |
| philiKON | or something like that | 22:23 |
| philiKON | and then you'd also just do <browser2:page factory=".MultiplePages" name="foo.html" /> and <browser2:page factory=".MultiplePages" name="bar.html" /> | 22:23 |
| regebro | OK. | 22:23 |
| philiKON | what does @publish do? | 22:23 |
| philiKON | it sets the dispatch table | 22:24 |
| philiKON | what you call class._pages i think | 22:24 |
| regebro | Ah. | 22:24 |
| philiKON | to the outside, MultiplePages behaves like a standard page. outside meaning the browser2:page directive | 22:24 |
| regebro | Yeah, OK, I kinda like having the naming in zcml. | 22:24 |
| philiKON | i agree | 22:24 |
| philiKON | which is why it's just an idea, not a proposal ;) | 22:25 |
| regebro | So 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 |
| philiKON | i'm not sure if i like modifying the class from zcml | 22:26 |
| philiKON | it has a monkey patch sort of feeling to it | 22:26 |
| philiKON | ideally, i would like pages to be registerable with zope.comopnent.provideAdapter | 22:26 |
| J1m | especially since a class might be used for multiple views. | 22:27 |
| philiKON | yep | 22:27 |
| regebro | Well, my code handles that, but currently without checks. ;) | 22:27 |
| regebro | But you are right, a real registry would be nice. | 22:28 |
| regebro | But can an adpater be just a method? | 22:28 |
| philiKON | an adapter is a whole object | 22:28 |
| * J1m isn't really paying attention | 22:28 | |
| philiKON | regebro, see, the point is this | 22:29 |
| * J1m is getting nervous seeing a reference to a registry | 22:29 | |
| philiKON | heh :) | 22:29 |
| philiKON | s/registry/dispatch table/ | 22:29 |
| * philiKON wonders if that made things worse | 22:29 | |
| philiKON | regebro, anyways. when we write adapters, we write one class per adapter, right? | 22:29 |
| regebro | With registry I mean "not just a mokeypatched dict". :) | 22:29 |
| regebro | philiKON: Yup. | 22:30 |
| philiKON | regebro, why can't we do that when we write pages? one page, one class. | 22:30 |
| J1m | philiKON, btw, sort of | 22:30 |
| J1m | I'm not happy about the dependence of zope.component.zcml on zope.security | 22:30 |
| regebro | Because you end up having loads of class that do nothing ecept act as placeholders. | 22:30 |
| philiKON | J1m, me neither | 22:30 |
| philiKON | regebro, well, that remains to be seen | 22:31 |
| philiKON | regebro, i haven't really tested browser2:page and this paradigm on a lot of code yet | 22:31 |
| philiKON | i'm not so sure that we'll create loads and loads of classes | 22:31 |
| J1m | we should consider moving that out. | 22:31 |
| philiKON | J1m, ok. | 22:31 |
| philiKON | J1m, were should be move it out then. the whole adapter directive (i think utility also) depends on protecting factories | 22:32 |
| regebro | Well, I'll end up with loads of class YetAnoteherClass(MyViewclass): __call__ = PageTemplateFile("yetanotherpagetemplate.pt") | 22:33 |
| J1m | I don't know. Let me think about it some more. | 22:33 |
| philiKON | regebro, for that you can use browser2:pageTemplate | 22:33 |
| philiKON | regebro, ah wait | 22:33 |
| philiKON | regebro, now i get it | 22:33 |
| J1m | why do we need a directive that allows multiple pages on the same view? | 22:33 |
| philiKON | the base class | 22:33 |
| regebro | J1m because I want it. :) | 22:33 |
| J1m | why? | 22:33 |
| philiKON | J1m, regebro argues to avoit repeating creating lots of classes | 22:34 |
| philiKON | avoid | 22:34 |
| J1m | I don't understand | 22:34 |
| regebro | Because thats what I end up with. | 22:34 |
| philiKON | J1m, say you have a set of page templates | 22:34 |
| philiKON | J1m, they all need auxiliary methods from a view class | 22:34 |
| philiKON | J1m, so far you'd put everything on one class | 22:34 |
| regebro | I have a class (say Event) and I need loads of pages on that class. | 22:34 |
| philiKON | the methods, the page templates | 22:34 |
| philiKON | etc. | 22:34 |
| philiKON | and register each template with the class individually as a browser:page | 22:35 |
| philiKON | without being able to register several pages from one class, you'd have to create a class for each one | 22:35 |
| philiKON | you might be able to put the commonly needed auxiliary methods on a base class | 22:35 |
| J1m | That's insane | 22:35 |
| philiKON | but you'll still have to create lots of classes | 22:35 |
| J1m | 1. You can use the same class for multiple pages | 22:35 |
| philiKON | we're not talking about now, we're talking about browser2:page | 22:36 |
| J1m | 2. You can use the browser:pages grouping directive to avoid having to repeat the class. | 22:36 |
| philiKON | yes, yes, i know | 22:36 |
| philiKON | we're talking about directives that won't create classes on the fly | 22:37 |
| regebro | Yes, but how to do it if we kill browser:page and browser:pages? | 22:37 |
| philiKON | browser:page and browser:pages create classes on the fly | 22:37 |
| *** MJ has joined #zope3-dev | 22:37 | |
| philiKON | browser2:page doesn't take a 'template' parameter | 22:37 |
| philiKON | it just takes a 'factory' parameter and registers this as an adapter | 22:37 |
| philiKON | the 'factory' has to implement zope.formlib.interfaces.IPage | 22:37 |
| philiKON | http://www.zope.org/DevHome/Wikis/DevSite/Projects/ComponentArchitecture/TheBrowserPageCompromise | 22:38 |
| regebro | Well, 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 |
| regebro | s/U/I | 22:40 |
| J1m | so the question is, are you going to create something better? Or just different. | 22:40 |
| regebro | Anybody who gets miffed that creating pages is a pain can use hello. :) | 22:40 |
| J1m | It looks like the latter. | 22:40 |
| philiKON | J1m, are you talking about my proposal? | 22:40 |
| J1m | yes | 22:41 |
| philiKON | as for browser2:pageTemplate and browser2:page, i'd say the former | 22:41 |
| J1m | You are still creating classes on the fly. | 22:41 |
| philiKON | only browser2:pagesFromClass | 22:41 |
| philiKON | it's part of that compromise | 22:41 |
| philiKON | for all icare, i wouldn't have it | 22:41 |
| philiKON | but people like regebro invariably want it | 22:41 |
| philiKON | browser2:pageTemplate and browser2:page are excessively stupid. | 22:42 |
| regebro | I think its just different, as I mentioned on the list. It moves complexity around, but doesn't remove it. | 22:42 |
| J1m | also browser2:pageTemplate | 22:42 |
| philiKON | J1m, ok, true | 22:42 |
| philiKON | J1m, but it's very very stupid about that | 22:42 |
| philiKON | browser2:pageTemplate is also a compromise :) | 22:42 |
| J1m | I really don't think this is worth the bother. | 22:43 |
| philiKON | too late: http://svn.zope.org/zope.browserzcml2/trunk/src/zope/browserzcml2/ :) | 22:43 |
| J1m | Yeah yeah | 22:43 |
| philiKON | my main motivator is browser2:page | 22:43 |
| J1m | BTW, I'll share a recent experience. | 22:44 |
| J1m | I had been away from z3 for a while. | 22:44 |
| J1m | I had to do a new registration UI. | 22:44 |
| J1m | My needs were quire simple. | 22:44 |
| J1m | My needs were quite simple. | 22:44 |
| J1m | zope.formlib.Page gave me almost everything I needed. | 22:45 |
| J1m | I could do all of my registrations via <adapter> | 22:45 |
| philiKON | great. browser2:page is the perfect companion for it :) | 22:45 |
| J1m | Even the security worked well. | 22:45 |
| philiKON | right | 22:45 |
| J1m | I don't need browser anything. | 22:46 |
| J1m | Just adapter | 22:46 |
| philiKON | so, the question is,s hould we encourage to teach people about registering zope.formlib.Page pages with <adapter /> | 22:46 |
| philiKON | ? | 22:46 |
| J1m | I'm not done. :) | 22:46 |
| philiKON | oh, sorry | 22:46 |
| philiKON | please continue | 22:46 |
| J1m | The only thing that stopped me was the lack of menu support. | 22:46 |
| J1m | The 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 |
| J1m | I could have used a browser:menuitem. but we sort of want to get rid of that too. | 22:48 |
| J1m | yes | 22:48 |
| J1m | so I just sucked it up and used browser:page. | 22:48 |
| philiKON | ah. how are we getting rid of it? | 22:48 |
| J1m | I thought we were. | 22:48 |
| philiKON | (btw, browser2:page does <adapter /> + menu) | 22:48 |
| philiKON | http://svn.zope.org/zope.browserzcml2/trunk/src/zope/browserzcml2/zcml.py?rev=67267&view=auto | 22:48 |
| philiKON | grep for "def page" | 22:49 |
| regebro | Well, 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 |
| philiKON | regebro, :) | 22:50 |
| regebro | I reserve the right to change my mind on this. :) | 22:50 |
| J1m | so for me, the only reason to use page is to get the menu defined. | 22:50 |
| J1m | Otherwise, I'd definately prefer adapter. | 22:50 |
| J1m | end of story :) | 22:50 |
| regebro | Yeah, well the hello-thingy is adapter + some traversal. | 22:50 |
| regebro | (and menu, althugh I ahven't tested that). | 22:51 |
| regebro | Now my gf wants to see a movie, so I'm gonna go. See ya tomorrow or something. | 22:51 |
| philiKON | bye | 22:52 |
| *** regebro has quit IRC | 22:53 | |
| *** dobee has quit IRC | 22:53 | |
| *** efrerich_ has joined #zope3-dev | 22:57 | |
| *** efrerich has quit IRC | 23:15 | |
| *** efrerich_ is now known as efrerich | 23:23 | |
| roym | My 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 IRC | 23:23 | |
| *** dunny has joined #zope3-dev | 23:25 | |
| roym | I guess what I am asking is could I tell addMenuItem to use the "+" view of object O. | 23:28 |
| *** SiggyF has quit IRC | 23:33 | |
| *** projekt01 has joined #zope3-dev | 23:36 | |
| roym | never 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 |
| projekt01 | roym, yup | 23:42 |
| *** MJ has joined #zope3-dev | 23:50 | |
| *** efrerich has quit IRC | 23:54 | |
| roym | projekt01: thanks. | 23:58 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!