| *** pcardune has joined #zope3-dev | 00:18 | |
| *** andres has joined #zope3-dev | 00:33 | |
| *** zbir has quit IRC | 00:47 | |
| *** _pcardune has joined #zope3-dev | 00:49 | |
| *** GaryPoster has quit IRC | 01:01 | |
| *** natea has quit IRC | 01:06 | |
| *** retsu has quit IRC | 01:06 | |
| *** _anguenot has quit IRC | 01:14 | |
| *** _anguenot has joined #zope3-dev | 01:14 | |
| *** andres_ has joined #zope3-dev | 01:33 | |
| *** andres has quit IRC | 01:33 | |
| *** elbixio has joined #zope3-dev | 01:36 | |
| *** sashav has quit IRC | 01:49 | |
| *** natea has joined #zope3-dev | 01:54 | |
| *** sashav has joined #zope3-dev | 01:55 | |
| *** zbir has joined #zope3-dev | 02:11 | |
| *** sashav has quit IRC | 02:13 | |
| *** tarek has quit IRC | 02:19 | |
| *** elbixio has quit IRC | 02:21 | |
| *** J1m has quit IRC | 02:25 | |
| *** retsu has joined #zope3-dev | 02:27 | |
| *** natea has quit IRC | 02:29 | |
| *** philiKON has quit IRC | 02:38 | |
| *** dman13 has joined #zope3-dev | 03:18 | |
| *** retsu has quit IRC | 03:21 | |
| *** yota has quit IRC | 03:35 | |
| *** benji has quit IRC | 03:39 | |
| *** MiUlEr has joined #zope3-dev | 04:02 | |
| *** tahara has joined #zope3-dev | 04:18 | |
| *** WebMaven has joined #zope3-dev | 04:32 | |
| *** retsu has joined #zope3-dev | 04:34 | |
| WebMaven | srichter: yo. | 04:46 |
|---|---|---|
| WebMaven | srichter: are you working on a new edition of the 'Zope 3 Developers Handbook'? | 04:47 |
| *** hazmat has joined #zope3-dev | 05:23 | |
| *** retsu has quit IRC | 05:38 | |
| *** hazmat is now known as haz_out | 05:48 | |
| *** retsu has joined #zope3-dev | 05:48 | |
| *** dman13 has quit IRC | 07:19 | |
| *** natea has joined #zope3-dev | 07:28 | |
| *** eins has joined #zope3-dev | 08:26 | |
| eins | morning | 08:26 |
| *** dobee has joined #zope3-dev | 08:45 | |
| *** dobee has quit IRC | 08:57 | |
| *** sashav has joined #zope3-dev | 09:21 | |
| *** MJ has quit IRC | 09:22 | |
| *** dobee has joined #zope3-dev | 09:25 | |
| *** sashav has quit IRC | 09:26 | |
| *** rom|aw has joined #zope3-dev | 09:46 | |
| *** zagy has joined #zope3-dev | 09:49 | |
| *** rom|aw is now known as romanofski | 10:03 | |
| romanofski | moin | 10:04 |
| *** pcardune_ has joined #zope3-dev | 10:04 | |
| *** jhauser has joined #zope3-dev | 10:05 | |
| *** _pcardune_ has joined #zope3-dev | 10:06 | |
| *** Theuni has joined #zope3-dev | 10:06 | |
| *** agroszer has joined #zope3-dev | 10:15 | |
| *** retsu has quit IRC | 10:21 | |
| *** pcardune has quit IRC | 10:21 | |
| *** _pcardune has quit IRC | 10:21 | |
| *** sashav has joined #zope3-dev | 10:31 | |
| *** d2m has quit IRC | 10:34 | |
| *** vlado has joined #zope3-dev | 10:42 | |
| *** MJ has joined #zope3-dev | 10:42 | |
| *** d2m has joined #zope3-dev | 10:49 | |
| *** retsu has joined #zope3-dev | 10:56 | |
| *** yota has joined #zope3-dev | 11:12 | |
| eins | how do I set my own permissions for adding objects through "/+/"? Zope requires zope.ManageContent permission to access "+" view | 11:13 |
| eins | romanofski hi | 11:13 |
| romanofski | eins: hi! | 11:22 |
| *** tarek has joined #zope3-dev | 11:25 | |
| *** retsu has quit IRC | 11:27 | |
| tahara | eins, you can set a permission using containerviews directive. | 11:41 |
| *** tarek has quit IRC | 11:45 | |
| *** tarek has joined #zope3-dev | 11:46 | |
| VladDrac | hmm I didn't know metal fill-slot can't be limited through tal:condition | 11:48 |
| VladDrac | lame :( | 11:48 |
| eins | thanks tahara, it worked :) | 11:48 |
| VladDrac | <metal:block fill-slot="someslot" tal:condition="condition"> .. </metal:block> | 11:49 |
| SteveA | VladDrac: well... | 11:57 |
| SteveA | you're relating two different things | 11:57 |
| SteveA | metal is one language | 11:57 |
| SteveA | it runs first | 11:57 |
| SteveA | tal is another language | 11:57 |
| SteveA | it is processed after the metal | 11:57 |
| VladDrac | so I noticed | 12:03 |
| VladDrac | I have a workaround, move the condition inside the fill-slot and reinclude the macro if false | 12:04 |
| VladDrac | but that's less clean imho | 12:04 |
| VladDrac | conceptually, <metal:macro is just another tag that can conditionally be included/excluded using tal | 12:05 |
| VladDrac | just like html, xml, whatever | 12:05 |
| SteveA | not really | 12:05 |
| VladDrac | but okay, it works, and it still alot better than kid :) | 12:05 |
| SteveA | because it is run first | 12:05 |
| SteveA | like macros in C | 12:05 |
| VladDrac | conceptually == in my brain :) | 12:05 |
| SteveA | tal:replace="structure template/macros/macroname" tal:condition="whatever" | 12:06 |
| SteveA | is maybe what you'd like to do | 12:06 |
| SteveA | i don't think that will work | 12:07 |
| VladDrac | I want to leave a slot untouched / replaced depending on a condition | 12:07 |
| *** ChrisW has joined #zope3-dev | 12:11 | |
| ChrisW | anyone here? | 12:11 |
| Theuni | SteveA: metal and tal are processed alternating iirc ... | 12:23 |
| ChrisW | ah, life :-) | 12:23 |
| ChrisW | is there any way to set a default skin at the site level? | 12:24 |
| Theuni | shouldn't it work by making a <tal:block> around the use-macro that does the condition? | 12:24 |
| Theuni | Hmm. Wait. this would just work even if the metal is executed. | 12:25 |
| Theuni | oh wait again ... you're talking about fill-slot | 12:25 |
| * ChrisW wonders if he's missing something of is Christian is really having a monologue ;-) | 12:26 | |
| Theuni | ChrisW: there was discussion before you entered :P~ | 12:26 |
| ChrisW | aha :-) | 12:26 |
| Theuni | :) | 12:26 |
| * ChrisW is all excited having finally gone through all of Philipp's book :-) | 12:27 | |
| ChrisW | apparently I'm a Zope 3 expert now ;-) | 12:27 |
| Theuni | *woot | 12:27 |
| ChrisW | yees | 12:28 |
| ChrisW | and bumping into the rough edges now ;-) | 12:28 |
| ChrisW | I am finally working on Swishdot ;-) | 12:28 |
| ChrisW | I have real code, for Zope 3 ;-) | 12:28 |
| ChrisW | (not much, mind) | 12:29 |
| ChrisW | okay, I'm only online for a short-ish time but I have looots of questions | 12:29 |
| ChrisW | zope3-users should get interesting when I'm back online properly ;-) | 12:29 |
| tahara | I refered schooltool source. | 12:34 |
| ChrisW | ? | 12:35 |
| tahara | see schoolToolTraverseSubscriber in http://source.schooltool.org/svn/trunk/schooltool/src/schooltool/app/browser/skin.py | 12:35 |
| ChrisW | sorry, not sure what you're referring to? | 12:36 |
| ChrisW | that lets you set a skin per site? | 12:36 |
| tahara | ah, I'm sorry. | 12:36 |
| tahara | yes. | 12:36 |
| ChrisW | oh, right | 12:36 |
| ChrisW | I'm suprised that isn't a core part of Zope 3's Site interface... | 12:36 |
| *** mgedmin has joined #zope3-dev | 12:38 | |
| *** alga has joined #zope3-dev | 12:38 | |
| *** philiKON has joined #zope3-dev | 12:47 | |
| ChrisW | hey Phil :-) | 12:57 |
| ChrisW | you here? | 12:58 |
| ChrisW | anyone know how big a checkout of http://source.schooltool.org/svn/trunk/ is going to be? | 12:59 |
| ChrisW | seems like it might be a good example app... | 12:59 |
| *** MJ has quit IRC | 13:00 | |
| *** ignas has joined #zope3-dev | 13:00 | |
| philiKON | hey ChrisW | 13:01 |
| ChrisW | hey Phil :-) | 13:01 |
| ChrisW | just wanted to thank you for the grat book | 13:01 |
| ChrisW | finally had a chance to read it all | 13:01 |
| ChrisW | just finishing up the security chapter now :-) | 13:01 |
| philiKON | cool :) | 13:01 |
| philiKON | i'm glad to hear that | 13:02 |
| *** mgedmin has quit IRC | 13:02 | |
| ChrisW | heh, I have so many questions now though | 13:02 |
| ChrisW | nothing like working offline for a couple of weeks with a book and a trunk checkout to leave me with lots to ask | 13:03 |
| philiKON | hehe | 13:03 |
| *** mgedmin has joined #zope3-dev | 13:03 | |
| ChrisW | most of it seems to be around how to make things happen at the site level | 13:03 |
| ChrisW | like, for example, setting a default skin for the site | 13:03 |
| philiKON | oh, hehe, yeah | 13:03 |
| ChrisW | someone suggested schooltool does this, but I saw no evidence of it | 13:04 |
| philiKON | technically possible | 13:04 |
| ChrisW | in zope 3 core | 13:04 |
| philiKON | just the UI is missing | 13:04 |
| philiKON | right | 13:04 |
| ChrisW | which is very suprising | 13:04 |
| ChrisW | (bear in mind I'm used to running many "sites" of one Zope instance) | 13:04 |
| philiKON | though I thought schooltool didn't use sites | 13:04 |
| ChrisW | where should I look? | 13:04 |
| philiKON | yes, running several sites in one zope instance is possible | 13:04 |
| philiKON | that's whole idea of sites | 13:05 |
| philiKON | (sites the concept) | 13:05 |
| philiKON | the functionality is there, as i said | 13:05 |
| ChrisW | yes, but it seems everything is geared up to provide stuff globally: skins, etc | 13:05 |
| philiKON | just a nice UI isn't | 13:05 |
| ChrisW | where would I look? | 13:05 |
| philiKON | feel free to write one :) | 13:05 |
| ChrisW | how should I wire it up? | 13:05 |
| ChrisW | (btw: I have finally started writing Swishdot now... all sorts of fun to be had :-D) | 13:05 |
| philiKON | haha! | 13:06 |
| mgedmin | ChrisW, schooltool *used* to set the skin for a site in a traversal subscriber | 13:06 |
| ChrisW | is there a style guide for what macros should be provided/slots filled/etc in order to be compatible with the Zope 3 style? | 13:06 |
| philiKON | i still remember your talk from EuroZope barbecue in 2001 or so where you "introduced" swishdot | 13:06 |
| mgedmin | then we decided to scrap the 'SchoolTool application as a content object inside a Zope 3 folder' use case | 13:06 |
| ChrisW | also, how far along is the "viewlet" concept? | 13:06 |
| mgedmin | and specified the default skin in zcml | 13:06 |
| ChrisW | ah, okay | 13:06 |
| mgedmin | if you're interested, you can find the old subscriber in subversion's history | 13:06 |
| ChrisW | so schooltool can no longer easily co-exist with other Zope 3 applications... that's a shame :-S | 13:07 |
| philiKON | well, that's not exactly true | 13:07 |
| philiKON | it just assumes certain defaults | 13:07 |
| philiKON | you are free to change them :) | 13:07 |
| ChrisW | (and, fwiw, the original Swishdot code has been in CVS for 5 years or so now ;-) ) | 13:07 |
| philiKON | anyways, there's a difference between setting the default skin and setting the skin dynamically upon traversal or some other funky way | 13:08 |
| ChrisW | philiKON: what are you talking about there? (too many cross conversations ;-) ) | 13:08 |
| philiKON | hehe | 13:08 |
| philiKON | i'm trying to explain to you what "default skin" means | 13:08 |
| philiKON | when a request is made, the default skin is applied to it | 13:08 |
| ChrisW | well, I think it'd be pretty important to be able to set the default skin at a site-level | 13:08 |
| philiKON | so, unless something else in the request's life changes that, the default skin applies | 13:09 |
| philiKON | yes | 13:09 |
| ChrisW | think of one Zope instance serving out 3 or 4 Squishdot sites... | 13:09 |
| philiKON | yes, yes | 13:09 |
| ChrisW | so what's the "right" way to do that? | 13:09 |
| *** andrew_m has joined #zope3-dev | 13:09 | |
| philiKON | lemme finish, goddam | 13:09 |
| philiKON | now, a skin is an interface that's registered as ISkin and with the name we know it as (e.g. "Rotterdam") | 13:10 |
| philiKON | the default skin is determined by looking up the default skin *name* | 13:10 |
| philiKON | which works somethign like this: | 13:10 |
| philiKON | IDefaultSkinName(request) | 13:10 |
| philiKON | ah, mmh, i take that back | 13:11 |
| philiKON | we actually *do* look up the skin itself | 13:11 |
| philiKON | IDefaultSkin(request) | 13:12 |
| philiKON | so, anyways, a UI that would do this at site level would simply register the skin interface as an adapter | 13:12 |
| philiKON | from IBrowserRequest to IDefaultSkin | 13:12 |
| philiKON | of course, since interfaces aren't picklable right now, this can only apply to skin interfaces defined in python | 13:13 |
| ChrisW | okay, but how do registrations like that take place at the site level? | 13:13 |
| philiKON | there's a registration API | 13:13 |
| ChrisW | "skin interfaces defined in python"? | 13:13 |
| ChrisW | and why aren't interfaces pickleable? | 13:13 |
| philiKON | even if they were it wouldn't do good | 13:13 |
| ChrisW | (I saw persistent schemas mentioned in the ZODB, do they not work now?) | 13:13 |
| philiKON | right, i don't think they work | 13:13 |
| philiKON | even if interfaces were picklable, you would persist an interface created in one run of the zope app and after a restart, ZCML would generate a new interface object which would then not be the same as the one sitting in the ZODB | 13:14 |
| philiKON | auto-generation of skins and layers just needs to end, i actually have a proposal for this that is just waiting to be implemented | 13:15 |
| ChrisW | hmm | 13:15 |
| philiKON | re: skin interfaces defined in python: | 13:15 |
| ChrisW | "auto-generation"? | 13:15 |
| *** nixnutz_ has joined #zope3-dev | 13:15 | |
| philiKON | yes, ZCML is evil that way | 13:15 |
| ChrisW | bear in mind I've read the book, but apart from that, I'm still a big fat n00b ;-) | 13:15 |
| ChrisW | ZCML is evil full stop | 13:15 |
| ChrisW | <rant coming> | 13:15 |
| philiKON | hehe | 13:15 |
| philiKON | well, if it were only about on/off switches, it wouldn't be so evil | 13:16 |
| ChrisW | so we've come up with yet another fucking language, great, complexity for complexity's saske, woohoo! | 13:16 |
| ChrisW | yes, but it isn't | 13:16 |
| philiKON | right, it isn't | 13:16 |
| ChrisW | think how much ZCML you wrie in tha tbook | 13:16 |
| philiKON | it's not for complexity's sake | 13:16 |
| ChrisW | and most of that is what I'd call programming | 13:16 |
| ChrisW | well, having it as another language is | 13:16 |
| ChrisW | especially as it likely maps onto python methods and objects underneath | 13:16 |
| philiKON | if it'd be python, people start doing evil hacks | 13:16 |
| philiKON | they start introducing 'if' clauses etc. | 13:17 |
| ChrisW | *shrugs* | 13:17 |
| philiKON | we don't want that | 13:17 |
| philiKON | just like we don't want to use python for generating HTML | 13:17 |
| ChrisW | have them behave like security proxies, where if people try and do evil hacks, it tells them not to | 13:17 |
| * mgedmin sometimes fears zope 3 is doomed to be huge and complex forever | 13:17 | |
| * ChrisW is with mgedmin | 13:17 | |
| philiKON | mgedmin, there are ways to make sure it won't be | 13:17 |
| ChrisW | that said, I still have dreams of my cms which will hide the complexity unless you really need it... | 13:17 |
| philiKON | ChrisW, anyways, to read about the status quo of skin interfaces etc., read the beginning of http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/SimplifySkinning | 13:18 |
| ChrisW | the constant use of adapters does worry me from a performance point of view | 13:18 |
| * andrew_m dreams of a layer between zope3 and a CMS that simplyfies stuff.. | 13:18 | |
| ChrisW | every single thing seems to involve insantiating a class and then calling it | 13:18 |
| philiKON | andrew_m, well, why not simplify zope3 itself | 13:18 |
| philiKON | ChrisW, so? | 13:18 |
| ChrisW | while that's not hugley expensive, it's also not trivially cheap ;-) | 13:18 |
| *** MJ has joined #zope3-dev | 13:19 | |
| ChrisW | zope3 needs it's complexity to meet everyone usecases and be ultimately felxible | 13:19 |
| philiKON | but i think there are ways it can "scale down" | 13:19 |
| ChrisW | however, _most_ people don't need to be exposed to that | 13:19 |
| philiKON | e.g. with the revival of bobo | 13:19 |
| ChrisW | I am very happy to see how things have come together | 13:19 |
| ChrisW | and yes, I can see how only little bits of it now _need_ to be used, which is great | 13:19 |
| ChrisW | I can see several mini-frameworks spinning off that do simpler things for what people need | 13:20 |
| ChrisW | and yet still allow them to side-grade to "full zope 3" if they really want it all | 13:20 |
| philiKON | well, yes, the idea of z3 is to be modular | 13:20 |
| philiKON | i think with our making zope.app smaller, it'll be even more modular | 13:21 |
| ChrisW | I can also see frameworks like Plohn and the one I'm brewing havign a full Zope 3 source tree but also providing much more targetted and flexible functionality for, say, a CMS | 13:21 |
| ChrisW | still Swishdot's going to make an interesting little experiement for me | 13:21 |
| philiKON | sure | 13:21 |
| philiKON | yeah, would also be a nice demo app | 13:21 |
| ChrisW | oh, tht reminds me, two big topics I need to dig on: | 13:22 |
| ChrisW | catalog | 13:22 |
| ChrisW | workflow | 13:22 |
| philiKON | i'm sure people would be willing to contribute, too, just to be able to play with z3 | 13:22 |
| philiKON | ping | 13:22 |
| ChrisW | where should I look? what should I read? | 13:22 |
| philiKON | err, sorry | 13:22 |
| philiKON | fwrong window | 13:22 |
| andrew_m | just a quicky: does someone know how i can get this very trivial doctest to work (i.e. "..." at the beginning of output): http://pastebin.com/491556 | 13:22 |
| philiKON | ChrisW, the doctests | 13:22 |
| philiKON | ChrisW, btw, are you not getting my /msgs? | 13:22 |
| ChrisW | I am, are you not getting mine? | 13:23 |
| ChrisW | oh, maybe not | 13:23 |
| ChrisW | fucking freenode bullshit | 13:23 |
| philiKON | nope, you're not registered then | 13:23 |
| andrew_m | ChrisW: you have to register / identify | 13:23 |
| philiKON | andrew_m, #doctest: +ELLIPSIS | 13:24 |
| mgedmin | ChrisW, the README and the source code of zope.wfmc are pretty good for understanding workflow | 13:24 |
| philiKON | andrew_m, http://pastebin.com/491564 | 13:24 |
| ChrisW | okay, and for cataloging? | 13:25 |
| philiKON | zope.app.catalog | 13:25 |
| mgedmin | andrew_m, I don't think you can -- the '...' is parsed as a continuation line; you must start the expected output section with something else | 13:26 |
| andrew_m | philiKON: ok, thanks. but it still refuses ellipses at the very beginning (first line of output) | 13:26 |
| ChrisW | philiKON: docs? | 13:26 |
| andrew_m | mgedmin: yeah :/ | 13:26 |
| mgedmin | andrew_m, in the worst case you can always do '>>> print "-"; do other stuff' | 13:26 |
| ChrisW | and, btw, I'm wary of doctests as documentation, they tend to end up only making sense if you're the author of them ;-) | 13:26 |
| andrew_m | mgedmin: heh, ok, that is an idea | 13:26 |
| mgedmin | ChrisW, documentation with doctests inside is great (working examples! an example is worth a thousand descriptions) | 13:27 |
| andrew_m | ChrisW: hmm.. i have leaned a lot from doctests though | 13:27 |
| andrew_m | learned | 13:27 |
| mgedmin | doctests that test the internals/corner cases/etc are useless as documentation | 13:27 |
| mgedmin | doctest is a tool with many uses | 13:27 |
| mgedmin | I count at least 4 | 13:28 |
| mgedmin | 1) short function usage examples in function docstrings | 13:28 |
| mgedmin | 2) long narrative-style developer documentation about the use of a package/module | 13:28 |
| mgedmin | 3) unit tests | 13:28 |
| mgedmin | 4) API design tool -- write some science fiction, try to make it into a doctest, then implement the code so that the test passes | 13:29 |
| ChrisW | yup | 13:29 |
| ChrisW | and only 2 is useful if you're in my position | 13:29 |
| ChrisW | I have to admit to being annoyed by 1, since most people don't really get the meaning of "short" | 13:30 |
| ChrisW | and doctest setup usually makes the docstring anything but short ;-) | 13:30 |
| mgedmin | it takes a while to get | 13:30 |
| andrew_m | ChrisW: yeah.. 1) makes me nervous (too much blah inside the code) | 13:31 |
| mgedmin | Jim's PyCon doctest presentation, and Phillip J. Eby's blog helped me | 13:31 |
| ChrisW | I _like_ doctests in files | 13:31 |
| ChrisW | but I don't think they're often documentation | 13:31 |
| ChrisW | zope.testbrowser was a good example for me ;-) | 13:31 |
| philiKON | sandwich time! | 13:33 |
| *** J1m has joined #zope3-dev | 13:44 | |
| *** AJC has joined #zope3-dev | 13:49 | |
| *** mkerrin has joined #zope3-dev | 13:49 | |
| *** ChrisW has left #zope3-dev | 13:49 | |
| *** J1m has quit IRC | 13:53 | |
| *** stub has joined #zope3-dev | 13:54 | |
| *** marwin has joined #zope3-dev | 14:30 | |
| marwin | hi guys. is this list for technicans or users ? | 14:32 |
| philiKON | you can ask questions about zope 3 here | 14:32 |
| marwin | cool :) | 14:33 |
| marwin | i used zope 2 before. now i have a look to zope 3... a very basic thing I nowhere found explained is: What is the difference between default and tools in ++etc++site ? | 14:34 |
| philiKON | nothing really | 14:35 |
| philiKON | just a different site management folder | 14:35 |
| marwin | so if I add something to default, it is exactly the same as I would add it do tools? there nothing different like visibility, local/global or something? | 14:36 |
| philiKON | nope | 14:37 |
| marwin | ok :) | 14:37 |
| marwin | tnx | 14:37 |
| marwin | oups, just realised that I created 'tools' by myself... I thougt it is also a default folder.... sorry about that. | 14:52 |
| *** roym has joined #zope3-dev | 14:57 | |
| roym | in z3, is it possible to pack the database from the GUI? | 14:58 |
| roym | I see a test: >>> ZODB.tests.util.pack(db) | 14:58 |
| Theuni | check the process management | 14:59 |
| Theuni | it might be there | 14:59 |
| Theuni | i'm not sure though | 14:59 |
| philiKON | roym, localhost:8080/++etc++process | 15:02 |
| philiKON | ... | 15:02 |
| roym | Thanks! | 15:02 |
| roym | I love how compact it is (vs Zope2) after packing. | 15:02 |
| *** tonico has quit IRC | 15:16 | |
| *** _anguenot has quit IRC | 15:17 | |
| *** stu1 has joined #zope3-dev | 15:24 | |
| *** stub has quit IRC | 15:24 | |
| *** tonico has joined #zope3-dev | 15:28 | |
| *** elbixio has joined #zope3-dev | 15:28 | |
| AJC | does it make sense to use rotterdam as a basis for a new skin, even if this new skin is extremely simple? | 15:29 |
| philiKON | perhaps not | 15:30 |
| philiKON | using rotterdam as a base skin is a pain | 15:30 |
| AJC | how so? | 15:30 |
| *** eins has quit IRC | 15:30 | |
| philiKON | it's inflexible | 15:31 |
| *** _pcardune_ has quit IRC | 15:33 | |
| *** pcardune_ has quit IRC | 15:33 | |
| AJC | ok, good enough for me :-) thanks. | 15:33 |
| *** stu1 is now known as stub | 15:33 | |
| AJC | is the difference between CPS and 3lab that the first uses Zope 2 and the latter Zope 3? | 15:35 |
| *** retsu has joined #zope3-dev | 15:36 | |
| AJC | z3lab.org i meant | 15:36 |
| *** tonico has quit IRC | 15:39 | |
| philiKON | AJC, z3lab.org runs CPS is | 15:40 |
| philiKON | AJC, z3lab.org runs CPS | 15:40 |
| AJC | ok, i was a bit confused by the relationship. so the next-gen open source ECM that z3lab wants to make is CPS? | 15:41 |
| *** benji has joined #zope3-dev | 15:41 | |
| jhauser | z3lab is not about a product or a specific framework | 15:42 |
| philiKON | AJC, z3lab is just a site | 15:42 |
| philiKON | AJC, it's not really a project | 15:42 |
| jhauser | z3lab at the moment collects components | 15:42 |
| jhauser | it represents somewhat the z3ecm project | 15:42 |
| *** tonico has joined #zope3-dev | 15:42 | |
| jhauser | the status of which I also do not know | 15:43 |
| philiKON | there's no status because there's no real project | 15:44 |
| AJC | hmm, i think i see :-) maybe you should have a small paragraph explaining this + linking to CPS, i had no idea about CPS until yesterday... | 15:45 |
| *** jinty has joined #zope3-dev | 15:46 | |
| *** J1m has joined #zope3-dev | 15:47 | |
| philiKON | AJC, so we should also have a link about Plone and Silva? seems a bit unnecessary | 15:47 |
| *** zbir has quit IRC | 15:50 | |
| AJC | i see your point. | 15:52 |
| *** retsu has quit IRC | 15:57 | |
| *** zbir has joined #zope3-dev | 16:01 | |
| *** tav has joined #zope3-dev | 16:02 | |
| *** j-w has joined #zope3-dev | 16:03 | |
| marwin | what is the simplest way to create a user login which can do the same as the default admin user? | 16:08 |
| marwin | is there something like a user_folder ? | 16:08 |
| philiKON | create a Pluggable Auth Utility | 16:10 |
| philiKON | create a principal folder inside | 16:10 |
| philiKON | create a principal | 16:11 |
| philiKON | then, grant that principal the zope.Manager role | 16:11 |
| marwin | hm. what is the prefix? or where is something like that documented? | 16:15 |
| *** stub has quit IRC | 16:16 | |
| philiKON | marwin, APIDoc, documentation, books... | 16:17 |
| *** jukart has joined #zope3-dev | 16:17 | |
| marwin | philiKON, did you write "Web Component Development with Zope 3" ? | 16:18 |
| philiKON | yes | 16:18 |
| marwin | we ordered it yesterday :) | 16:19 |
| andrew_m | marwin: good idea.. helps a lot especially in the beginning | 16:19 |
| J1m | Some things I want in the next release cycle: | 16:30 |
| J1m | - Move as much as possible out of zope.app | 16:30 |
| J1m | - Much simpler local component management. | 16:31 |
| J1m | - Better publishing APIs. | 16:31 |
| J1m | Rethink/do repo/packaging w eggs | 16:31 |
| J1m | bl | 16:31 |
| J1m | bbl | 16:31 |
| *** retsu has joined #zope3-dev | 16:38 | |
| J1m | back | 16:45 |
| philiKON | J1m, two questions | 16:47 |
| benji | I'd suggest we make Z3 compatible with Paste, and thus get egg support | 16:47 |
| philiKON | a) will the moving out of zope.app be only mechanical (meaning, the 'app' in the import path will disappear), or will it basically be large refactorings as well? | 16:48 |
| philiKON | and: | 16:48 |
| philiKON | b) how simple will the local component management be? | 16:48 |
| philiKON | do we know yet? | 16:48 |
| J1m | a) It will be mechanical, except that it is motivated by making things more modular and is likely to inspire further refactoring. | 16:50 |
| J1m | b) : | 16:50 |
| philiKON | cool | 16:50 |
| J1m | - Get rid of registration managers | 16:51 |
| J1m | - components can be registered either from anywhere. This means site-management folders will be less magic. They will simplty provide a convenient way to keep things out of content space. | 16:52 |
| J1m | - From python, components will be registered more or less as they are now with the global component registry. | 16:52 |
| philiKON | that sounds great | 16:53 |
| philiKON | question about the first bullet point: | 16:53 |
| J1m | So, for example, creating a local utility will be as simple as calling provideUtility on some local thing. | 16:53 |
| philiKON | how will registrations be managed? | 16:53 |
| srichter | which brings me to the point that we should really rid ourselves of the old local CA BBB code | 16:53 |
| J1m | Internally by the component manager (currently called site manager) | 16:54 |
| srichter | it will be hell to write new BBB code otherwise | 16:54 |
| philiKON | J1m, i see. so basically, registration managers are folded into site managers | 16:55 |
| philiKON | other than that, this is exactly what i had in mind for CMF 2.0 local components | 16:55 |
| philiKON | been meaning to put that into my draft proposal | 16:55 |
| philiKON | the one i'll work on at pycon | 16:56 |
| philiKON | perhaps we can take some time to brain storm on this | 16:56 |
| philiKON | so the architectures will be similar | 16:56 |
| philiKON | meaning, brainstorm on it at pycon :) | 16:56 |
| *** retsu has quit IRC | 16:57 | |
| * jinty would really like to be involved in any discussion about zope+eggs | 16:58 | |
| jinty | as it has the potential to make debian packaging much easier, or harder | 16:59 |
| philiKON | benji, interesting suggestion. i need to read up on paste | 16:59 |
| benji | me too :) | 16:59 |
| philiKON | jinty, which reminds me, i've always wanted to write this blog entry why eggs and tradition packaging formats like debs and rpm don't contradict... | 17:00 |
| philiKON | jinty, i think it'll make debian packaging much easier | 17:00 |
| mgedmin | philiKON, +1 for writing it | 17:00 |
| philiKON | :) | 17:01 |
| jinty | philiKON: eggs and packages were bad for each other until we got the --single-version-externally-managed shoot myself in the foot option | 17:01 |
| philiKON | what's --single-version-externally -managed? | 17:02 |
| jinty | it's a little option for setuptools that does not build eggs | 17:02 |
| philiKON | so, what does it build? | 17:03 |
| jinty | but exploded directories maintaining the egg metadata | 17:03 |
| philiKON | cool | 17:03 |
| philiKON | but why can't a deb just install an egg? | 17:03 |
| philiKON | i mean, debs install JAR files too | 17:03 |
| jinty | I don't think it's necessary | 17:04 |
| jinty | but I am not sure of the exact reasons | 17:04 |
| jinty | but here goes anyway | 17:04 |
| jinty | an egg is a single file, so un-installing is easy, i.e. you dont have to keep track of the files | 17:05 |
| jinty | but a debian package keeps track of the files, and make sure they are un-installed correctly | 17:06 |
| philiKON | yeah, but can a debian package with single files actually manage separate versions of something | 17:06 |
| philiKON | ? | 17:06 |
| jinty | i don't understand the question | 17:06 |
| philiKON | with eggs, you can install more than one version of the same package | 17:07 |
| philiKON | e.g. you can install zope 3.1 and 3.2 in sites-packages | 17:07 |
| jinty | but only one is active at a time? | 17:07 |
| jinty | i.e. import zope will only import one of those, right? | 17:08 |
| philiKON | well, if my personal package says "require("Zope <= 3.10")", then eggs will figure out and put zope 3.1 into the pythonpath | 17:08 |
| benji | jinty, you can use the -m (IIRC) option to have multiple eggs "active" (but I'm not sure about the details, I'm an egg newbe) | 17:08 |
| philiKON | right, multiple ones can be active | 17:08 |
| philiKON | and it decides from the metadata whidch one to use | 17:09 |
| jinty | I think what will happen in this case is that the eggs in debian packages will contribute one of thse versions | 17:10 |
| jinty | because they have the metadata | 17:11 |
| jinty | but I am rapidly getting out of my depth here | 17:11 |
| jinty | ;) | 17:11 |
| jinty | there is a huge thread on debian-python that goes through most issues | 17:13 |
| jinty | if you can dee through the flames (me is embarrassed at the behaviour of some debian developers) | 17:13 |
| philiKON | heh, yeah | 17:14 |
| philiKON | exactly the point of "eggs vs. tradition packaging" | 17:14 |
| jinty | eggs try to solve a problem that was already solved in debian for many years | 17:15 |
| jinty | that gets people irritated | 17:16 |
| philiKON | right | 17:16 |
| philiKON | but it solves more even | 17:16 |
| jinty | starts here: http://lists.debian.org/debian-python/2005/11/msg00008.html | 17:17 |
| benji | unfortunately the "all the world is debian" attitude doesn't help much here :) | 17:17 |
| philiKON | right | 17:18 |
| mgedmin | yeah, some of us use ubuntu | 17:18 |
| * mgedmin ducks and runs | 17:18 | |
| philiKON | lol | 17:19 |
| srichter | benji: I agree | 17:19 |
| srichter | I think it is very important for Python to have a solid dependency/packaging system independent of any OS | 17:20 |
| philiKON | jinty, holy jeebus, what a thread | 17:20 |
| dobee | hi all, is ther some kind of timezone change to zope 3.2 b3? on a fresh instance when i create a folder the dates i see in the browser does not match the ones i get in the log. the log dates match my machine | 17:21 |
| dobee | my machine: Darwin bd-mb 8.3.0 Darwin Kernel Version 8.3.0: Mon Oct 3 20:04:04 PDT 2005; root:xnu-792.6.22.obj~2/RELEASE_PPC Power Macintosh powerpc | 17:21 |
| jinty | benji, srichter: I agree, but not actually breaking debian (or ubuntu) would be nice as well | 17:22 |
| srichter | of course | 17:24 |
| benji | right | 17:24 |
| srichter | but if there are conflicting recommendations/policies you have to choose one | 17:24 |
| benji | I was just noting that the scope of our considerations is much wider than that of the debian team (non-debian linux, Windows, Mac, etc.) | 17:25 |
| J1m | philiKON, I want Z2 and Z3 to manage local components the same way, ideally with the same code. | 17:29 |
| philiKON | me too | 17:29 |
| J1m | There are all sorts of other things I want for Z2. :) | 17:29 |
| philiKON | but we want something like this in cmf 2.x | 17:30 |
| philiKON | which might only require zope 2.9/3.2 | 17:30 |
| philiKON | or perhaps not | 17:30 |
| philiKON | lots of tings to brainstorm at in dallas | 17:30 |
| J1m | yup | 17:30 |
| *** retsu has joined #zope3-dev | 17:31 | |
| *** _anguenot has joined #zope3-dev | 17:33 | |
| philiKON | g'night y'all | 17:33 |
| romanofski | nighty philiKON | 17:33 |
| *** jinty has quit IRC | 17:40 | |
| mgedmin | stylistic question: should doctest sections in a ReStructuredText file (*.txt) be indented with 2 spaces or 4? | 17:42 |
| * mgedmin prefers 4 | 17:42 | |
| * mgedmin 's editor prefers 4 would be a bit more accurate | 17:42 | |
| benji | mgedmin, 4 | 17:43 |
| * philiKON prefers 2 space indention in all reST files | 17:43 | |
| *** marwin has quit IRC | 17:43 | |
| philiKON | meaning, the >>> is on the 3rd column | 17:43 |
| mgedmin | I know | 17:44 |
| mgedmin | in a preformatted section:: | 17:44 |
| mgedmin | if there is python code: | 17:45 |
| mgedmin | it is better to keep all indents a multiple of 4 spaces | 17:45 |
| mgedmin | otherwise it looks strange | 17:45 |
| mgedmin | >>> and I want to align all indented blocks the same way | 17:45 |
| mgedmin | </over> | 17:45 |
| benji | that's one reason why I prefer 4, that's how the code will be indented | 17:46 |
| philiKON | so, you indent quotes 4 spaces as well? | 17:46 |
| benji | I do | 17:46 |
| J1m | I indent >>>s 4 spaces. | 17:46 |
| philiKON | *sigh* ok :) | 17:46 |
| philiKON | </over-and-out> | 17:47 |
| *** jhauser has quit IRC | 18:01 | |
| *** sashav has quit IRC | 18:05 | |
| *** jhauser has joined #zope3-dev | 18:05 | |
| *** dobee has quit IRC | 18:11 | |
| *** romanofski has quit IRC | 18:16 | |
| *** mgedmin has quit IRC | 18:21 | |
| *** MacYET has joined #zope3-dev | 18:22 | |
| *** andrew_m has quit IRC | 18:23 | |
| srichter | philiKON: I prefer 2 :-) | 18:25 |
| *** jukart has left #zope3-dev | 18:26 | |
| *** zagy has quit IRC | 18:27 | |
| benji | Cardinal Biggles, prepair the comfy chair for the heratic, srichter! | 18:30 |
| *** dobee has joined #zope3-dev | 18:31 | |
| * MacYET hands some soft cushions | 18:31 | |
| * benji searches franticly for... THE RACK! | 18:32 | |
| *** natea is now known as natea|away | 18:32 | |
| *** andrew_m has joined #zope3-dev | 18:34 | |
| *** elbixio has quit IRC | 18:45 | |
| *** mgedmin has joined #zope3-dev | 18:49 | |
| *** efge has joined #zope3-dev | 18:49 | |
| efge | J1m: I saw your email. Actually I just committed my temporary fix in MountedObject.py. I'll remove it if needed. | 18:50 |
| J1m | I'm just about to send a second message. | 18:51 |
| J1m | Do you know why the temporary storage isn't part of the multidb to start with? | 18:51 |
| efge | J1m: yes, it's opened by the mountpoint traversal, and it doesn't add it to the multidb connection set | 18:52 |
| J1m | I'm not asking about the connection. | 18:52 |
| J1m | Just ream my mail ... | 18:52 |
| J1m | Just read my mail ... | 18:53 |
| J1m | :) | 18:53 |
| efge | that's a problem only the first time it's done in the zope life, when the DB for the temporarystorage hasn't been created yet | 18:53 |
| J1m | sent | 18:53 |
| J1m | Why isn't the temporary database used by the session machinery part of the multiedb to start with? | 18:55 |
| efge | J1m: ok I understand the question | 18:55 |
| J1m | anyway, aside from not having enough tests, I don't think there is a ZODB bug here. | 18:56 |
| efge | I don't know why, something in the DBTab layers fails to register it | 18:56 |
| efge | J1m: agreed | 18:56 |
| J1m | So I'll tell Tim to proceed with 3.6 final so I can proceed with 3.2 final. | 18:57 |
| MacYET | when you expect 3.2 final? | 18:58 |
| MacYET | when do you expect 3.2 final? | 18:58 |
| efge | J1m: hm the database isnt't added to the multidb until it's opened | 18:58 |
| efge | and it's not opened until the mountpoint traverses it | 18:58 |
| efge | datatypes.DBTab.getDatabase() does that | 18:59 |
| J1m | Sounds like a DBTab bug. | 19:00 |
| *** mgedmin_ has joined #zope3-dev | 19:00 | |
| *** MJ has quit IRC | 19:00 | |
| J1m | Is it possible for that code to add the database to the multidb and then retry get_connection? | 19:01 |
| efge | J1m: should dbtab open all registered databases at startup? | 19:01 |
| efge | J1m: that could work yes | 19:01 |
| J1m | Yes, it should | 19:02 |
| J1m | But if that's too hard to change, then a sane runtime approach would be fine. | 19:03 |
| J1m | Where sane is as described above. | 19:03 |
| efge | J1m: ok I'll try that and check it in if it's working | 19:04 |
| J1m | Cool. Thanks! | 19:04 |
| efge | probably not today though | 19:04 |
| *** xenru has joined #zope3-dev | 19:05 | |
| J1m | k | 19:06 |
| efge | J1m: DBTab.getDatabase has an is_root arg which passed by zope's startup code but never use | 19:11 |
| efge | used | 19:11 |
| efge | we could open all databases at that point if is_root is true | 19:11 |
| J1m | Does it know about all of the databases at that point? | 19:11 |
| J1m | I've always thought that DBTab should *really* be like fstab. | 19:12 |
| efge | yes that's after configuration has been loaded, the mount_paths dict has been filled | 19:12 |
| J1m | fstab doesn't define devices. It just configures how they're used. | 19:12 |
| J1m | k | 19:12 |
| MacYET | jim: where is the generations package? | 19:13 |
| J1m | IN the long run, I'd prefer that the multi-databases be defined outside of DBTab and have DBTab just specify where databases (by name) get mounted. | 19:13 |
| J1m | MacYET, zope.app.generations | 19:14 |
| J1m | Of course, that should move out of zope.app. :) | 19:14 |
| MacYET | tnx | 19:15 |
| efge | J1m: quick ZODB question: I don't have a clear understanding of the difference between a tid and an object's serial, are they the same? | 19:16 |
| J1m | No | 19:16 |
| *** mgedmin has quit IRC | 19:16 | |
| J1m | They can be different. | 19:16 |
| *** zagy has joined #zope3-dev | 19:16 | |
| J1m | They are usually the same, but they aren't guarenteed to be the same. | 19:17 |
| *** mgedmin_ has quit IRC | 19:21 | |
| *** mcdonc_ has joined #zope3-dev | 19:27 | |
| efge | J1m: would there be a problem if a storaged defined serials independently of tids? Are they ever compared or one used for the other? | 19:31 |
| *** MJ has joined #zope3-dev | 19:32 | |
| *** natea|away is now known as natea | 19:35 | |
| *** tarek has quit IRC | 19:39 | |
| *** retsu has quit IRC | 19:42 | |
| AJC | see you guys! | 19:42 |
| *** AJC has quit IRC | 19:42 | |
| *** zagy has quit IRC | 19:55 | |
| *** deo has quit IRC | 19:59 | |
| *** j-w has quit IRC | 20:04 | |
| *** mcdonc_ has quit IRC | 20:05 | |
| *** efge has quit IRC | 20:06 | |
| *** nixnutz_ has quit IRC | 20:09 | |
| *** regebro has joined #zope3-dev | 20:21 | |
| regebro | Hiya all! | 20:21 |
| regebro | I'm a bit confused. | 20:21 |
| *** vlado has quit IRC | 20:22 | |
| regebro | zope.app.testing.placelesssetup imports from zope.component.tests.placelesssetup. | 20:22 |
| regebro | But to the best I can figure out... it's deprecated!? | 20:22 |
| regebro | OK, just a miss I guess, then. | 20:25 |
| regebro | Why on earth is placelesssetup starting with doing a cleanup!? Sigh. | 20:34 |
| regebro | My tests first loads some stuff, then installs all necessary products, the does a cleanup and then a load_site. Then placeless setup does a new cleanup, meaning I then need too, once again, do a new load_site. | 20:35 |
| regebro | And I'm not even sure THAT works. :-/ | 20:35 |
| regebro | OK, that seems to work at least. :-) | 20:38 |
| *** mgedmin has joined #zope3-dev | 20:40 | |
| *** deo has joined #zope3-dev | 20:46 | |
| *** tiredbones has quit IRC | 20:55 | |
| *** tiredbones has joined #zope3-dev | 21:01 | |
| *** Aiste has quit IRC | 21:23 | |
| *** MacYET has quit IRC | 21:32 | |
| *** agroszer has quit IRC | 21:40 | |
| *** dman13 has joined #zope3-dev | 21:44 | |
| *** ignas has quit IRC | 21:47 | |
| *** Aiste has joined #zope3-dev | 21:56 | |
| *** mkerrin has quit IRC | 22:11 | |
| *** TwistedBen has joined #zope3-dev | 22:21 | |
| *** MacYET has joined #zope3-dev | 22:34 | |
| *** MacYET has quit IRC | 22:40 | |
| *** _anguenot has quit IRC | 22:40 | |
| *** regebro has quit IRC | 22:44 | |
| *** tarek has joined #zope3-dev | 22:48 | |
| *** romanofski has joined #zope3-dev | 23:17 | |
| *** jenner has joined #zope3-dev | 23:18 | |
| jenner | heya | 23:18 |
| benji | hi, jenner | 23:25 |
| jenner | hi benji | 23:27 |
| jenner | Does anyone have a decent example of formlib usage? | 23:28 |
| *** dman13 has quit IRC | 23:32 | |
| *** alga has quit IRC | 23:35 | |
| benji | jenner, the formlib doctests are good, read the first section carefully though, because it points to the easier-to-use section later in the document | 23:36 |
| jenner | benji: thnx | 23:36 |
| *** romanofski has quit IRC | 23:40 | |
| *** romanofski has joined #zope3-dev | 23:41 | |
| *** romanofski has joined #zope3-dev | 23:42 | |
| *** efrerich has joined #zope3-dev | 23:44 | |
| *** jinty has joined #zope3-dev | 23:47 | |
| *** sashav has joined #zope3-dev | 23:49 | |
| *** jenner has quit IRC | 23:57 | |
| *** zbir has quit IRC | 23:57 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!