IRC log of #zope3-dev for Thursday, 2005-05-05

*** SureshZ has quit IRC00:20
*** bskahan has joined #zope3-dev00:29
*** srichter has quit IRC00:30
*** RaFromBRC has quit IRC00:59
*** niemeyer has quit IRC01:00
*** bskahan has quit IRC01:02
*** srichter has joined #zope3-dev01:28
*** ChanServ sets mode: +o srichter01:30
*** GaryPoster has joined #zope3-dev01:33
*** J1m has quit IRC02:08
*** alga has joined #zope3-dev02:23
*** GaryPoster has quit IRC02:57
*** srichter has quit IRC03:12
*** alga has quit IRC03:14
*** srichter has joined #zope3-dev03:14
*** ChanServ sets mode: +o srichter03:16
srichter`anthony: are you there?03:25
*** ignas has joined #zope3-dev03:27
*** projekt01 has left #zope3-dev03:34
*** stub has joined #zope3-dev04:10
*** jeru has quit IRC04:58
*** tvon has joined #zope3-dev04:58
*** yota has joined #zope3-dev05:20
*** MiUlEr has joined #zope3-dev05:28
*** MiUlEr has quit IRC05:34
*** lordMiUlEr has joined #zope3-dev05:34
*** MiUlEr has joined #zope3-dev05:36
*** lordMiUlEr has quit IRC05:36
*** GaryPoster has joined #zope3-dev05:38
*** MiUlEr is now known as MiUlErlog05:48
*** kaczordek has joined #zope3-dev06:41
*** stub has quit IRC06:43
*** GaryPoster has quit IRC06:50
*** MiUlErlog has quit IRC07:01
*** GaryPoster has joined #zope3-dev07:21
*** vinsci has quit IRC07:31
*** GaryPoster has quit IRC07:52
*** yota has quit IRC07:57
*** RaFromBRC has joined #zope3-dev08:12
*** RaFromBRC has quit IRC08:15
*** RaFromBRC has joined #zope3-dev08:15
*** viyyer has joined #zope3-dev08:15
*** RaFromBRC has joined #zope3-dev08:16
*** RaFromBRC has joined #zope3-dev08:16
*** yota has joined #zope3-dev08:22
*** sarca has joined #zope3-dev08:37
*** viyyer has quit IRC08:38
*** sarca is now known as viyyer08:38
*** RaFromBRC has quit IRC08:49
*** hdima has joined #zope3-dev08:54
`anthonysrichter: am now09:22
*** Aiste has joined #zope3-dev09:36
*** irc_sprout has joined #zope3-dev09:37
*** d2m has quit IRC09:45
*** `anthony has quit IRC09:50
*** Aiste has quit IRC09:51
*** Aiste has joined #zope3-dev09:51
*** stub has joined #zope3-dev10:04
*** Aiste has quit IRC10:13
*** RaFromBRC has joined #zope3-dev10:26
*** MacYET__ has joined #zope3-dev10:34
*** RaFromBRC has quit IRC10:40
*** MacYET__ has quit IRC11:01
*** MacYET__ has joined #zope3-dev11:10
*** RaFromBRC has joined #zope3-dev11:32
*** zagy_ has joined #zope3-dev11:36
*** MacYET__ has quit IRC11:36
*** MacYET__ has joined #zope3-dev11:38
*** kaczordek has quit IRC11:56
*** MacYET__ has quit IRC11:59
*** alga has joined #zope3-dev12:02
*** MacYET__ has joined #zope3-dev12:07
*** Aiste has joined #zope3-dev12:09
*** vinsci has joined #zope3-dev12:10
*** MacYET__ has quit IRC12:48
*** Aiste has quit IRC12:53
*** RaFromBRC has quit IRC12:53
*** MacYET__ has joined #zope3-dev12:56
*** MacYET__ has quit IRC13:00
*** projekt01 has joined #zope3-dev13:02
*** bskahan has joined #zope3-dev13:09
*** Aiste has joined #zope3-dev13:12
*** bskahan has quit IRC13:26
*** viyyer has quit IRC13:37
*** viyyer has joined #zope3-dev13:38
*** bskahan has joined #zope3-dev13:39
*** stub has quit IRC13:44
*** stub has joined #zope3-dev13:45
*** ignas_ has joined #zope3-dev13:58
*** bskahan has quit IRC14:05
*** bskahan has joined #zope3-dev14:12
*** zagy_ is now known as zagy14:22
*** vlado has joined #zope3-dev14:32
*** srichter has quit IRC14:33
*** viyyer has quit IRC15:29
*** zagy has left #zope3-dev15:36
*** viyyer has joined #zope3-dev15:39
*** srichter has joined #zope3-dev15:39
*** ChanServ sets mode: +o srichter15:40
*** zagy has joined #zope3-dev15:50
*** zagy has joined #zope3-dev15:50
srichterhdima: thanks a lot for fixing all those bugs15:54
srichterhdimawhen you have fixed a bug, you can move it CHANGES.txt instead of another location in TODO.txt15:54
srichterthe goal is to get TODO.txt to be empty15:54
hdimaok, I'll drop the records later15: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
srichterhdima: why is this i18n"translate="" bogus?15:56
hdimabecause tal:content replace the message15:57
srichterbut in this case what i18n:translate should do is to translate the message15:58
srichternote that message ids should not be translated unless an i18n:translate attribute was provided15:58
hdimai18nextract translate such cases to 'XXX' since message ID is unknown15:59
hdimaso you should translate tal:content value before16:00
srichterusually those message ids are picked up in the Python code extraction16:01
srichterit is a limitation/misfeature of i18nextract that it does not get the message id correct16:01
srichterin fact, it should ignore those cases16:01
*** SureshZ has joined #zope3-dev16:02
srichterso now you effectively turned off the translation of the message above16:02
hdimahmm... ok maybe I've missunderstand. I'll check this all later16:03
srichterso please review this checkin again16:03
*** philiKON has joined #zope3-dev16:03
srichterand correct the incorrect removals16:03
srichternote that several other cleanups in this checkin are good and correct16:03
hdimaok and then I'll remove 'XXX' marks from tal/i18nextract16:04
srichterthat would be great!16:04
hdimaseems like I'm in hurry :)16:05
hdimaI'll correct this all tomorrow16:06
srichteryes, I will not hold you up any longer :-)16:06
srichterno problem16:06
*** mexiKON has quit IRC16:11
*** niemeyer has joined #zope3-dev16:17
*** hdima has quit IRC16:24
*** GaryPoster has joined #zope3-dev16:31
*** __gotcha has joined #zope3-dev16:47
*** GaryPoster has quit IRC16:50
*** GaryPoster has joined #zope3-dev16:50
srichterGaryPoster: I did not know about invariants17:05
srichtergood to know that we have them17:05
srichterGaryPoster: Is it really that much work to add them to the form framework?17:06
GaryPosterYes, they are good stuff--if your form machinery displays them.  No, it's pretty easy.17:06
srichterI think it would be good to add this for 3.1, no?17:06
GaryPosterSure.  The only slightly tricky bit is testing an invariant during an add, but that isn't too bad17:07
srichterGaryPoster: Could you add the feature to the trunk?17:07
GaryPosterYou just have to come up with a faux object that implements just enough of the interface.17:07
srichterI guess you could implement a __getattr__ for the faux object that always returns the null value of the field17:08
GaryPosterI'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-dev17:08
GaryPosterYeah, we have something like that17:09
GaryPosterOK, I'll try to get something in soon17:09
srichterhdima did some great work recently; if there would be one or two more people like that, life would be much better17:09
GaryPosteryeah :-/17:10
*** `anthony has joined #zope3-dev17:10
*** mohsen has joined #zope3-dev17:13
*** mohsen is now known as mohsen|away17:13
*** mohsen|away is now known as mohsen17:13
*** bskahan has quit IRC17:14
projekt01GaryPoster, I will love it to see invariants working ;-)17:17
GaryPosterprojekt01: ok, I'll try to get that soon :-)17:18
projekt01Don't hurry17:19
projekt01I just think this is a missing part which can enhance the form concept to a good, complete solution.17:20
projekt01Is it possible to notify a event in a event subscriber?17:33
projekt01Or do we have a event order where I can say which event has to be the first, second etc17:34
srichterno event ordering17:36
srichterthough the issue came up before17:37
srichterI think you can solve this via event channels17:37
srichteran event that spawns another event17:37
projekt01Spawns means "notify another event from a event subscriber"? Right?17:39
projekt01Ok, I'll try this, thanks17:40
*** viyyer has quit IRC17:42
*** J1m has joined #zope3-dev17:43
*** viyyer has joined #zope3-dev17:47
*** SteveA_ has joined #zope3-dev17:49
*** SteveA_ has joined #zope3-dev17:51
*** SteveA has quit IRC17:56
*** viyyer has quit IRC17:59
*** alga has quit IRC18:01
*** MacYET_ has joined #zope3-dev18:06
*** vlado has quit IRC18:17
*** jeru has joined #zope3-dev18:18
jeruhi all, I#18:18
jeruI'm trying to get ldapauth up and running18:19
jerubut where can I add a local "Authentication Service" in ++etc++site?18:19
SteveA_how odd18:20
srichterIt's called Local Authenication Utility now18:20
SteveA_while i do know nothing about this software, i'd have expected ldap authentication to be per-process, and configured in zcml18:20
srichterno, it is a data plugin for PAU18:21
jerusrichter: thanks, so I should add a PAU ?18:22
* VladDrac somewhat wonders what everyone's currently doing with Zope318:22
VladDrac(except writing books about it :)18:22
srichterjeru: yeah18:22
MacYET_cursing it :18:22
MacYET_just kidding :)18:23
srichterMacYET_: really? I thought you love it. :-)18:23
philiKONVladDrac, canonical is writing schooltool/bell18:23
philiKONand i presume since it's 1.0, it's running already18:23
SteveA_not really18:23
MacYET_srichter: in general yes :)18:23
* VladDrac knows about schooltool/bell18:23
philiKONSteveA_, uh, correct me :)18:24
VladDracthe only z3 app I know of (and zemantic, somewhat)18:24
SteveA_the shuttleworth foundation is funding development on schooltool and schoolbell18:24
philiKONah, ok18:24
* VladDrac mostly knows stevea as the schooltool guy18:24
SteveA_canonical is using zope3 for "launchpad", the "backoffice" of the ubuntu linux distro18:24
philiKONVladDrac, 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 utility18:25
philiKONMacYET_, yup18:25
SteveA_or rather, one per name18:25
philiKONone per (interface, name) combination18:25
SteveA_you can tell philiKON is an author ;-)18:26
srichterMacYET_: getUtility() only looks up a component18:26
srichteronly getAdapter() creates one using its contexts18:26
MacYET_and the only way is to use createObject() using a registered IFactory?18:27
srichteryes, but createObject() is more meant for content components18:27
philiKONnot sure about that18:27
MacYET_it should not matter18:28
philiKONcreateObject 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_object is object18:28
srichterphiliKON: 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
philiKONMacYET_, do they need to be instantiated when you do the lookup?18:30
MacYET_yes and no18:30
MacYET_depends on the utility :-=18:30
srichterutilities cannot be instantiated at lookup18:31
srichterthen you should use null-adapters18:31
MacYET_at txng lookup time18:31
philiKONnull-adapters might not be such a bad idea18:31
*** ignas_ has quit IRC18:32
* MacYET_ notes that18:33
*** stub has quit IRC18:36
philiKONare there any z3 sprints planned now for EP05?18:46
MacYET_no idea18:47
MacYET_since nobody responded i won't attend one :)18:47
* philiKON needs to plan his trip18:48
MacYET_finally got a hotel today18:48
philiKONi'll stay at the SGS again18:48
MacYET_nah..too bad beds...not good for my back :)18:49
MacYET_you know...old man :)18:49
philiKONsure, grandpa :)18:49
MacYET_yes, son :)18:49
* MacYET_ goes to the concert18:50
*** MacYET_ has left #zope3-dev18:50
*** bskahan_ has joined #zope3-dev19:14
*** bska|mobile has quit IRC19:16
*** SteveA_ has quit IRC19:29
*** alga has joined #zope3-dev19:45
J1mcreateObject is just an abstraction for object construction.20:10
J1mWe find it useful because it makes it easy to swap content classes.20:10
J1mThis reminds me of am issue i've been meaning to raise on the list.20:11
*** ignas_ has joined #zope3-dev20:15
*** SteveA_ has joined #zope3-dev20:19
*** d2m has joined #zope3-dev21:03
*** SteveA__ has joined #zope3-dev21:05
*** SteveA__ is now known as SteveA21:05
*** mgedmin has joined #zope3-dev21:11
*** SteveA_ has quit IRC21:13
*** mkerrin has joined #zope3-dev21:44
*** RaFromBRC has joined #zope3-dev22:20
*** alga has quit IRC22:30
*** mgedmin has quit IRC22:32
*** Aiste has quit IRC22:35
projekt01What's the best solution for ordering the directly provided interfaces in a object?22:41
SteveAwhy do you need to do that?22:42
SteveAthe API allows for it22:42
SteveAbut i think it makes for a fragile system22:42
projekt01We allow to mark objects with interfaces, but I have to make sure that the order is correct.22:43
projekt01I know the order of each possible marker22:43
projekt01I'm looking for a concept how I can order this markers.22:43
projekt01A marker adapts some addition functionality to the object.22:44
SteveAi don't see why the order is significant22:45
projekt01E.g. If each marker has a edit.html view, it's relevant which marker is the first.22:45
SteveAwhen you use the directlyProvides / directlyProvidedBy API, you're replacing all the directly provided interfaces on the object with a new set22:45
SteveAso, you can totally control the order of the directly provided interfaces22:46
*** hazmat has joined #zope3-dev22:46
SteveAbut, as i said, i think it makes for a very fragile system.22:46
SteveAand, fragility makes for bitrot and bugs that come out of unexpected interactions22:47
projekt01Yes, that's right in general. I implement some parts where this should make more stable.22:48
*** Aiste has joined #zope3-dev22:48
projekt01I think directlyProvides is not the fragile part, it's just important that you can control it.22:50
SteveAthe fragile part is having the correct functioning of your system depend on the ordering of interfaces22:51
SteveAthat an object provides22:51
* srichter tends to agree with SteveA22:51
projekt01Yes, I like to define this order as "the only one order" for a object.22:51
projekt01Then you can provide marker and they get every time correctly ordered added.22:52
projekt01Then it's not fragile anymore in your definition. Right?22:52
SteveAfraid so22:53
SteveAlet's say your defined order is IA, IB, IC, ID22:53
*** `anthony has quit IRC22:53
*** `anthony has joined #zope3-dev22:54
SteveAnow, let's say I have a class that implements ID and IA22:54
SteveAwhat would you expect to happen in that case?22:54
SteveAi have not yet directly provided any interfaces on an object that is an instance of that class22:54
*** ignas_ has quit IRC22:54
SteveAdo i need to ensure i declare the interfaces in a particular order in the implements() line ?22:54
srichteruuh, that's a recipe for disaster22:55
projekt01Yup, we mark interface a possible markers, it's not possible to implement this markers directly in a class.22:56
SteveAif you need to control which of several edit views is found,22:56
projekt01Markers are more keys for some kind of plugins22:56
SteveAthen you might consider having an edit view that dispatches to an appropriate other registered edit view, based on some particular set of rules22:57
*** Aiste has quit IRC22:57
srichterthat's a good idea22:57
srichterlike we do it for widgets22:57
projekt01SteveA, that's also a good concept22:57
SteveAit is easier to communicate to people who are reading the code / understanding the system you're buiding22:58
projekt01I use the marker more as a interface for to add plugins.22:58
SteveAyeah, that's a useful pattern.  just don't depend on the order ;-)22:58
* SteveA --> afk22:59
projekt01The usecase of different marker override other views should not happen.22:59
projekt01I just looking for a fallback szenario22:59
SteveAi would advise failing early rather than programming defensively22:59
SteveAerm, they probably mean the same thing :-)23:00
SteveAwhat i mean is, don't add code for situations that shouldn't happen anyway23:00
SteveAinstead, add checks / tests / assertions that such things will not happen23:01
SteveAso, in this case, if you expect to not have the same view name registered for more than one of your selection of interfaces23:01
SteveAthen write a test that gets run at start-up that looks up some view names on each of those interfaces23:02
SteveAand ensures that there are no overlaps23:02
SteveAfor example23:02
* SteveA --> really afk for several hours23:03
*** `anthony has quit IRC23:03
projekt01SteveA, 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-dev23:15
*** mkerrin has quit IRC23:22

Generated by 2.15.1 by Marius Gedminas - find it at!