| *** SureshZ has quit IRC | 00:20 | |
| *** bskahan has joined #zope3-dev | 00:29 | |
| *** srichter has quit IRC | 00:30 | |
| *** RaFromBRC has quit IRC | 00:59 | |
| *** niemeyer has quit IRC | 01:00 | |
| *** bskahan has quit IRC | 01:02 | |
| *** srichter has joined #zope3-dev | 01:28 | |
| *** ChanServ sets mode: +o srichter | 01:30 | |
| *** GaryPoster has joined #zope3-dev | 01:33 | |
| *** J1m has quit IRC | 02:08 | |
| *** alga has joined #zope3-dev | 02:23 | |
| *** GaryPoster has quit IRC | 02:57 | |
| *** srichter has quit IRC | 03:12 | |
| *** alga has quit IRC | 03:14 | |
| *** srichter has joined #zope3-dev | 03:14 | |
| *** ChanServ sets mode: +o srichter | 03:16 | |
| srichter | `anthony: are you there? | 03:25 |
|---|---|---|
| *** ignas has joined #zope3-dev | 03:27 | |
| *** projekt01 has left #zope3-dev | 03:34 | |
| *** stub has joined #zope3-dev | 04:10 | |
| *** jeru has quit IRC | 04:58 | |
| *** tvon has joined #zope3-dev | 04:58 | |
| *** yota has joined #zope3-dev | 05:20 | |
| *** MiUlEr has joined #zope3-dev | 05:28 | |
| *** MiUlEr has quit IRC | 05:34 | |
| *** lordMiUlEr has joined #zope3-dev | 05:34 | |
| *** MiUlEr has joined #zope3-dev | 05:36 | |
| *** lordMiUlEr has quit IRC | 05:36 | |
| *** GaryPoster has joined #zope3-dev | 05:38 | |
| *** MiUlEr is now known as MiUlErlog | 05:48 | |
| *** kaczordek has joined #zope3-dev | 06:41 | |
| *** stub has quit IRC | 06:43 | |
| *** GaryPoster has quit IRC | 06:50 | |
| *** MiUlErlog has quit IRC | 07:01 | |
| *** GaryPoster has joined #zope3-dev | 07:21 | |
| *** vinsci has quit IRC | 07:31 | |
| *** GaryPoster has quit IRC | 07:52 | |
| *** yota has quit IRC | 07:57 | |
| *** RaFromBRC has joined #zope3-dev | 08:12 | |
| *** RaFromBRC has quit IRC | 08:15 | |
| *** RaFromBRC has joined #zope3-dev | 08:15 | |
| *** viyyer has joined #zope3-dev | 08:15 | |
| *** RaFromBRC has joined #zope3-dev | 08:16 | |
| *** RaFromBRC has joined #zope3-dev | 08:16 | |
| *** yota has joined #zope3-dev | 08:22 | |
| *** sarca has joined #zope3-dev | 08:37 | |
| *** viyyer has quit IRC | 08:38 | |
| *** sarca is now known as viyyer | 08:38 | |
| *** RaFromBRC has quit IRC | 08:49 | |
| *** hdima has joined #zope3-dev | 08:54 | |
| `anthony | srichter: am now | 09:22 |
| *** Aiste has joined #zope3-dev | 09:36 | |
| *** irc_sprout has joined #zope3-dev | 09:37 | |
| *** d2m has quit IRC | 09:45 | |
| *** `anthony has quit IRC | 09:50 | |
| *** Aiste has quit IRC | 09:51 | |
| *** Aiste has joined #zope3-dev | 09:51 | |
| *** stub has joined #zope3-dev | 10:04 | |
| *** Aiste has quit IRC | 10:13 | |
| *** RaFromBRC has joined #zope3-dev | 10:26 | |
| *** MacYET__ has joined #zope3-dev | 10:34 | |
| *** RaFromBRC has quit IRC | 10:40 | |
| *** MacYET__ has quit IRC | 11:01 | |
| *** MacYET__ has joined #zope3-dev | 11:10 | |
| *** RaFromBRC has joined #zope3-dev | 11:32 | |
| *** zagy_ has joined #zope3-dev | 11:36 | |
| *** MacYET__ has quit IRC | 11:36 | |
| *** MacYET__ has joined #zope3-dev | 11:38 | |
| *** kaczordek has quit IRC | 11:56 | |
| *** MacYET__ has quit IRC | 11:59 | |
| *** alga has joined #zope3-dev | 12:02 | |
| *** MacYET__ has joined #zope3-dev | 12:07 | |
| *** Aiste has joined #zope3-dev | 12:09 | |
| *** vinsci has joined #zope3-dev | 12:10 | |
| *** MacYET__ has quit IRC | 12:48 | |
| *** Aiste has quit IRC | 12:53 | |
| *** RaFromBRC has quit IRC | 12:53 | |
| *** MacYET__ has joined #zope3-dev | 12:56 | |
| *** MacYET__ has quit IRC | 13:00 | |
| *** projekt01 has joined #zope3-dev | 13:02 | |
| *** bskahan has joined #zope3-dev | 13:09 | |
| *** Aiste has joined #zope3-dev | 13:12 | |
| *** bskahan has quit IRC | 13:26 | |
| *** viyyer has quit IRC | 13:37 | |
| *** viyyer has joined #zope3-dev | 13:38 | |
| *** bskahan has joined #zope3-dev | 13:39 | |
| *** stub has quit IRC | 13:44 | |
| *** stub has joined #zope3-dev | 13:45 | |
| *** ignas_ has joined #zope3-dev | 13:58 | |
| *** bskahan has quit IRC | 14:05 | |
| *** bskahan has joined #zope3-dev | 14:12 | |
| *** zagy_ is now known as zagy | 14:22 | |
| *** vlado has joined #zope3-dev | 14:32 | |
| *** srichter has quit IRC | 14:33 | |
| *** viyyer has quit IRC | 15:29 | |
| *** zagy has left #zope3-dev | 15:36 | |
| *** viyyer has joined #zope3-dev | 15:39 | |
| *** srichter has joined #zope3-dev | 15:39 | |
| *** ChanServ sets mode: +o srichter | 15:40 | |
| *** zagy has joined #zope3-dev | 15:50 | |
| *** zagy has joined #zope3-dev | 15:50 | |
| srichter | hdima: thanks a lot for fixing all those bugs | 15:54 |
| srichter | hdimawhen you have fixed a bug, you can move it CHANGES.txt instead of another location in TODO.txt | 15:54 |
| srichter | the goal is to get TODO.txt to be empty | 15:54 |
| hdima | ok, I'll drop the records later | 15:56 |
| srichter | </form> | 15:56 |
| srichter | - <div tal:content="options/message|nothing" i18n:translate="" /> | 15:56 |
| srichter | + <div tal:content="options/message|nothing" /> | 15:56 |
| srichter | 15:56 | |
| srichter | </div> | 15:56 |
| srichter | hdima: why is this i18n"translate="" bogus? | 15:56 |
| hdima | because tal:content replace the message | 15:57 |
| srichter | but in this case what i18n:translate should do is to translate the message | 15:58 |
| srichter | note that message ids should not be translated unless an i18n:translate attribute was provided | 15:58 |
| hdima | i18nextract translate such cases to 'XXX' since message ID is unknown | 15:59 |
| hdima | so you should translate tal:content value before | 16:00 |
| srichter | no | 16:01 |
| hdima | ? | 16:01 |
| srichter | usually those message ids are picked up in the Python code extraction | 16:01 |
| srichter | it is a limitation/misfeature of i18nextract that it does not get the message id correct | 16:01 |
| hdima | yes | 16:01 |
| srichter | in fact, it should ignore those cases | 16:01 |
| *** SureshZ has joined #zope3-dev | 16:02 | |
| srichter | so now you effectively turned off the translation of the message above | 16:02 |
| hdima | hmm... ok maybe I've missunderstand. I'll check this all later | 16:03 |
| srichter | so please review this checkin again | 16:03 |
| *** philiKON has joined #zope3-dev | 16:03 | |
| srichter | (30249) | 16:03 |
| srichter | and correct the incorrect removals | 16:03 |
| srichter | note that several other cleanups in this checkin are good and correct | 16:03 |
| hdima | ok and then I'll remove 'XXX' marks from tal/i18nextract | 16:04 |
| srichter | that would be great! | 16:04 |
| hdima | seems like I'm in hurry :) | 16:05 |
| hdima | I'll correct this all tomorrow | 16:06 |
| srichter | yes, I will not hold you up any longer :-) | 16:06 |
| srichter | no problem | 16:06 |
| hdima | :) | 16:07 |
| *** mexiKON has quit IRC | 16:11 | |
| *** niemeyer has joined #zope3-dev | 16:17 | |
| *** hdima has quit IRC | 16:24 | |
| *** GaryPoster has joined #zope3-dev | 16:31 | |
| *** __gotcha has joined #zope3-dev | 16:47 | |
| *** GaryPoster has quit IRC | 16:50 | |
| *** GaryPoster has joined #zope3-dev | 16:50 | |
| srichter | GaryPoster: I did not know about invariants | 17:05 |
| srichter | good to know that we have them | 17:05 |
| srichter | GaryPoster: Is it really that much work to add them to the form framework? | 17:06 |
| GaryPoster | Yes, they are good stuff--if your form machinery displays them. No, it's pretty easy. | 17:06 |
| srichter | I think it would be good to add this for 3.1, no? | 17:06 |
| GaryPoster | Sure. The only slightly tricky bit is testing an invariant during an add, but that isn't too bad | 17:07 |
| srichter | GaryPoster: Could you add the feature to the trunk? | 17:07 |
| GaryPoster | You just have to come up with a faux object that implements just enough of the interface. | 17:07 |
| GaryPoster | OK... | 17:07 |
| srichter | yeah | 17:08 |
| srichter | I guess you could implement a __getattr__ for the faux object that always returns the null value of the field | 17:08 |
| GaryPoster | I'm guessing we still don't have enough traction with bug fixes to have a concrete 3.1 delivery date? | 17:08 |
| *** bska|mobile has joined #zope3-dev | 17:08 | |
| srichter | right | 17:08 |
| GaryPoster | Yeah, we have something like that | 17:09 |
| GaryPoster | OK, I'll try to get something in soon | 17:09 |
| srichter | hdima did some great work recently; if there would be one or two more people like that, life would be much better | 17:09 |
| srichter | great | 17:09 |
| GaryPoster | yeah :-/ | 17:10 |
| *** `anthony has joined #zope3-dev | 17:10 | |
| *** mohsen has joined #zope3-dev | 17:13 | |
| *** mohsen is now known as mohsen|away | 17:13 | |
| *** mohsen|away is now known as mohsen | 17:13 | |
| *** bskahan has quit IRC | 17:14 | |
| projekt01 | GaryPoster, I will love it to see invariants working ;-) | 17:17 |
| GaryPoster | projekt01: ok, I'll try to get that soon :-) | 17:18 |
| projekt01 | Don't hurry | 17:19 |
| projekt01 | I just think this is a missing part which can enhance the form concept to a good, complete solution. | 17:20 |
| projekt01 | Is it possible to notify a event in a event subscriber? | 17:33 |
| projekt01 | Or do we have a event order where I can say which event has to be the first, second etc | 17:34 |
| srichter | no event ordering | 17:36 |
| srichter | though the issue came up before | 17:37 |
| srichter | I think you can solve this via event channels | 17:37 |
| srichter | an event that spawns another event | 17:37 |
| projekt01 | Spawns means "notify another event from a event subscriber"? Right? | 17:39 |
| srichter | yes | 17:40 |
| projekt01 | Ok, I'll try this, thanks | 17:40 |
| *** viyyer has quit IRC | 17:42 | |
| *** J1m has joined #zope3-dev | 17:43 | |
| *** viyyer has joined #zope3-dev | 17:47 | |
| *** SteveA_ has joined #zope3-dev | 17:49 | |
| *** SteveA_ has joined #zope3-dev | 17:51 | |
| *** SteveA has quit IRC | 17:56 | |
| *** viyyer has quit IRC | 17:59 | |
| *** alga has quit IRC | 18:01 | |
| *** MacYET_ has joined #zope3-dev | 18:06 | |
| MacYET_ | morning | 18:06 |
| *** vlado has quit IRC | 18:17 | |
| *** jeru has joined #zope3-dev | 18:18 | |
| jeru | hi all, I# | 18:18 |
| jeru | I'm trying to get ldapauth up and running | 18:19 |
| jeru | but where can I add a local "Authentication Service" in ++etc++site? | 18:19 |
| SteveA_ | how odd | 18:20 |
| srichter | It's called Local Authenication Utility now | 18:20 |
| SteveA_ | while i do know nothing about this software, i'd have expected ldap authentication to be per-process, and configured in zcml | 18:20 |
| srichter | no, it is a data plugin for PAU | 18:21 |
| jeru | srichter: thanks, so I should add a PAU ? | 18:22 |
| * VladDrac somewhat wonders what everyone's currently doing with Zope3 | 18:22 | |
| VladDrac | (except writing books about it :) | 18:22 |
| srichter | jeru: yeah | 18:22 |
| MacYET_ | cursing it : | 18:22 |
| MacYET_ | :) | 18:23 |
| MacYET_ | just kidding :) | 18:23 |
| srichter | MacYET_: really? I thought you love it. :-) | 18:23 |
| philiKON | VladDrac, canonical is writing schooltool/bell | 18:23 |
| philiKON | and i presume since it's 1.0, it's running already | 18:23 |
| SteveA_ | um | 18:23 |
| SteveA_ | not really | 18:23 |
| MacYET_ | srichter: in general yes :) | 18:23 |
| * VladDrac knows about schooltool/bell | 18:23 | |
| philiKON | SteveA_, uh, correct me :) | 18:24 |
| VladDrac | the only z3 app I know of (and zemantic, somewhat) | 18:24 |
| SteveA_ | the shuttleworth foundation is funding development on schooltool and schoolbell | 18:24 |
| philiKON | ah, ok | 18:24 |
| * VladDrac mostly knows stevea as the schooltool guy | 18:24 | |
| SteveA_ | canonical is using zope3 for "launchpad", the "backoffice" of the ubuntu linux distro | 18:24 |
| philiKON | VladDrac, well, zemantic isn't an application of itself... | 18:24 |
| MacYET_ | getUtility() can not be used to create multiple instances for a registered utility? | 18:24 |
| SteveA_ | there is *one* instance of a zcml defined utility | 18:25 |
| philiKON | MacYET_, yup | 18:25 |
| SteveA_ | or rather, one per name | 18:25 |
| philiKON | one per (interface, name) combination | 18:25 |
| SteveA_ | http://www.zdnet.com.au/news/software/0,2000061733,39190252,00.htm | 18:26 |
| SteveA_ | you can tell philiKON is an author ;-) | 18:26 |
| srichter | MacYET_: getUtility() only looks up a component | 18:26 |
| srichter | only getAdapter() creates one using its contexts | 18:26 |
| MacYET_ | and the only way is to use createObject() using a registered IFactory? | 18:27 |
| srichter | yes, but createObject() is more meant for content components | 18:27 |
| philiKON | not sure about that | 18:27 |
| MacYET_ | it should not matter | 18:28 |
| philiKON | createObject is meant to be used with IFactories, whatever those are... if it's convenient for MacYET_ to use factories for instanciation, why not use that infrastructure... | 18:28 |
| MacYET_ | right | 18:28 |
| MacYET_ | object is object | 18:28 |
| srichter | philiKON: ask J1m, I just had a discussion with him about this recently :-) | 18:28 |
| SteveA_ | i have utilities that keep state in a threadlocal, so i effectively have one utility per thread for these ones. it's been a useful tool. | 18:28 |
| MacYET_ | otherwise how would you create multiple utilites except by calling the factory directly? | 18:29 |
| philiKON | MacYET_, do they need to be instantiated when you do the lookup? | 18:30 |
| MacYET_ | yes and no | 18:30 |
| MacYET_ | depends on the utility :-= | 18:30 |
| srichter | utilities cannot be instantiated at lookup | 18:31 |
| srichter | then you should use null-adapters | 18:31 |
| MacYET_ | at txng lookup time | 18:31 |
| philiKON | null-adapters might not be such a bad idea | 18:31 |
| *** ignas_ has quit IRC | 18:32 | |
| * MacYET_ notes that | 18:33 | |
| *** stub has quit IRC | 18:36 | |
| philiKON | are there any z3 sprints planned now for EP05? | 18:46 |
| MacYET_ | no idea | 18:47 |
| MacYET_ | since nobody responded i won't attend one :) | 18:47 |
| * philiKON needs to plan his trip | 18:48 | |
| MacYET_ | finally got a hotel today | 18:48 |
| philiKON | i'll stay at the SGS again | 18:48 |
| MacYET_ | nah..too bad beds...not good for my back :) | 18:49 |
| MacYET_ | you know...old man :) | 18:49 |
| philiKON | sure, grandpa :) | 18:49 |
| MacYET_ | yes, son :) | 18:49 |
| * MacYET_ goes to the concert | 18:50 | |
| MacYET_ | bye | 18:50 |
| *** MacYET_ has left #zope3-dev | 18:50 | |
| *** bskahan_ has joined #zope3-dev | 19:14 | |
| *** bska|mobile has quit IRC | 19:16 | |
| *** SteveA_ has quit IRC | 19:29 | |
| *** alga has joined #zope3-dev | 19:45 | |
| J1m | createObject is just an abstraction for object construction. | 20:10 |
| J1m | We find it useful because it makes it easy to swap content classes. | 20:10 |
| J1m | This reminds me of am issue i've been meaning to raise on the list. | 20:11 |
| *** ignas_ has joined #zope3-dev | 20:15 | |
| *** SteveA_ has joined #zope3-dev | 20:19 | |
| *** d2m has joined #zope3-dev | 21:03 | |
| *** SteveA__ has joined #zope3-dev | 21:05 | |
| *** SteveA__ is now known as SteveA | 21:05 | |
| *** mgedmin has joined #zope3-dev | 21:11 | |
| *** SteveA_ has quit IRC | 21:13 | |
| *** mkerrin has joined #zope3-dev | 21:44 | |
| *** RaFromBRC has joined #zope3-dev | 22:20 | |
| *** alga has quit IRC | 22:30 | |
| *** mgedmin has quit IRC | 22:32 | |
| *** Aiste has quit IRC | 22:35 | |
| projekt01 | What's the best solution for ordering the directly provided interfaces in a object? | 22:41 |
| SteveA | why do you need to do that? | 22:42 |
| SteveA | the API allows for it | 22:42 |
| SteveA | but i think it makes for a fragile system | 22:42 |
| projekt01 | We allow to mark objects with interfaces, but I have to make sure that the order is correct. | 22:43 |
| projekt01 | I know the order of each possible marker | 22:43 |
| projekt01 | I'm looking for a concept how I can order this markers. | 22:43 |
| projekt01 | A marker adapts some addition functionality to the object. | 22:44 |
| SteveA | i don't see why the order is significant | 22:45 |
| projekt01 | E.g. If each marker has a edit.html view, it's relevant which marker is the first. | 22:45 |
| SteveA | when you use the directlyProvides / directlyProvidedBy API, you're replacing all the directly provided interfaces on the object with a new set | 22:45 |
| SteveA | so, you can totally control the order of the directly provided interfaces | 22:46 |
| *** hazmat has joined #zope3-dev | 22:46 | |
| SteveA | but, as i said, i think it makes for a very fragile system. | 22:46 |
| SteveA | and, fragility makes for bitrot and bugs that come out of unexpected interactions | 22:47 |
| projekt01 | Yes, that's right in general. I implement some parts where this should make more stable. | 22:48 |
| *** Aiste has joined #zope3-dev | 22:48 | |
| projekt01 | I think directlyProvides is not the fragile part, it's just important that you can control it. | 22:50 |
| SteveA | the fragile part is having the correct functioning of your system depend on the ordering of interfaces | 22:51 |
| SteveA | that an object provides | 22:51 |
| * srichter tends to agree with SteveA | 22:51 | |
| projekt01 | Yes, I like to define this order as "the only one order" for a object. | 22:51 |
| projekt01 | Then you can provide marker and they get every time correctly ordered added. | 22:52 |
| projekt01 | Then it's not fragile anymore in your definition. Right? | 22:52 |
| SteveA | fraid so | 22:53 |
| SteveA | let's say your defined order is IA, IB, IC, ID | 22:53 |
| *** `anthony has quit IRC | 22:53 | |
| *** `anthony has joined #zope3-dev | 22:54 | |
| SteveA | now, let's say I have a class that implements ID and IA | 22:54 |
| SteveA | what would you expect to happen in that case? | 22:54 |
| SteveA | i have not yet directly provided any interfaces on an object that is an instance of that class | 22:54 |
| *** ignas_ has quit IRC | 22:54 | |
| SteveA | do i need to ensure i declare the interfaces in a particular order in the implements() line ? | 22:54 |
| srichter | uuh, that's a recipe for disaster | 22:55 |
| projekt01 | Yup, we mark interface a possible markers, it's not possible to implement this markers directly in a class. | 22:56 |
| SteveA | if you need to control which of several edit views is found, | 22:56 |
| projekt01 | Markers are more keys for some kind of plugins | 22:56 |
| SteveA | then you might consider having an edit view that dispatches to an appropriate other registered edit view, based on some particular set of rules | 22:57 |
| *** Aiste has quit IRC | 22:57 | |
| srichter | that's a good idea | 22:57 |
| srichter | like we do it for widgets | 22:57 |
| projekt01 | SteveA, that's also a good concept | 22:57 |
| SteveA | it is easier to communicate to people who are reading the code / understanding the system you're buiding | 22:58 |
| projekt01 | I use the marker more as a interface for to add plugins. | 22:58 |
| SteveA | yeah, that's a useful pattern. just don't depend on the order ;-) | 22:58 |
| * SteveA --> afk | 22:59 | |
| projekt01 | The usecase of different marker override other views should not happen. | 22:59 |
| projekt01 | I just looking for a fallback szenario | 22:59 |
| SteveA | i would advise failing early rather than programming defensively | 22:59 |
| SteveA | erm, they probably mean the same thing :-) | 23:00 |
| SteveA | what i mean is, don't add code for situations that shouldn't happen anyway | 23:00 |
| SteveA | instead, add checks / tests / assertions that such things will not happen | 23:01 |
| SteveA | so, in this case, if you expect to not have the same view name registered for more than one of your selection of interfaces | 23:01 |
| SteveA | then write a test that gets run at start-up that looks up some view names on each of those interfaces | 23:02 |
| SteveA | and ensures that there are no overlaps | 23:02 |
| SteveA | for example | 23:02 |
| * SteveA --> really afk for several hours | 23:03 | |
| *** `anthony has quit IRC | 23:03 | |
| projekt01 | SteveA, thanks for the hints. I think about it. Perhaps I do it this way if I don't see a reason to have to override views or adapters. | 23:05 |
| *** `anthony has joined #zope3-dev | 23:15 | |
| *** mkerrin has quit IRC | 23:22 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!