| *** alga has joined #SchoolTool | 00:36 | |
| *** jinty has quit IRC | 01:07 | |
| *** tiredbones has quit IRC | 02:10 | |
| *** tiredbones has joined #schooltool | 02:10 | |
| *** didymo has joined #schooltool | 02:20 | |
| *** Hwyvar has quit IRC | 03:33 | |
| *** cabbie has joined #schooltool | 03:48 | |
| *** th1a has quit IRC | 03:48 | |
| *** alga has quit IRC | 04:14 | |
| *** didymo has quit IRC | 06:33 | |
| *** cabbie has quit IRC | 06:54 | |
| *** jinty has joined #schooltool | 08:51 | |
| *** ignas has joined #schooltool | 11:26 | |
| *** ignas has quit IRC | 11:32 | |
| *** jinty has quit IRC | 11:46 | |
| *** faassen has joined #schooltool | 12:14 | |
| *** thisfred has joined #schooltool | 12:49 | |
| *** jinty has joined #schooltool | 13:02 | |
| *** Aiste has quit IRC | 13:03 | |
| *** Aiste has joined #schooltool | 13:21 | |
| *** alga has joined #SchoolTool | 13:36 | |
| *** mgedmin has joined #schooltool | 15:10 | |
| povbot | /svn/commits: * faassen committed revision 6035: | 15:56 |
|---|---|---|
| povbot | /svn/commits: Add batching/sortable zc.table based tabular display for demographics persons. Integrated schooltool.batching macros with zc.table so that things work nicely together. This results in a TablePage class which can be reused through subclassing - after it's moved to an appropriate location. | 15:56 |
| povbot | /svn/commits: Had to turn manager into a demographics.person.Person first; this error was obscured because the evolution script had updated this in my database. | 15:56 |
| *** aircool00 has joined #schooltool | 16:11 | |
| *** aircool00 has left #schooltool | 16:15 | |
| povbot | /svn/commits: * faassen committed revision 6036: | 16:36 |
| povbot | /svn/commits: No form needed. This should be further adjusted to fit the schooltool style. | 16:36 |
| povbot | /svn/commits: * faassen committed revision 6037: | 16:36 |
| povbot | /svn/commits: Add a schooldata screen. Needs quite a lot of tweaking still (custom drop-down lists, form layout broken somehow, proper date input widget). | 16:36 |
| povbot | /svn/commits: * faassen committed revision 6038: | 17:17 |
| povbot | /svn/commits: Add various contact info screens (parent1, parent2, emergency1-3). | 17:17 |
| *** th1a has joined #schooltool | 18:00 | |
| *** alga has quit IRC | 18:00 | |
| *** th1a has quit IRC | 18:01 | |
| *** th1a|x60s has joined #schooltool | 18:04 | |
| povbot | /svn/commits: * gintas committed revision 6039: | 18:14 |
| povbot | /svn/commits: Show conflicts in relationship editing views. | 18:14 |
| mgedmin | faassen: buildbot blames you for breaking unit and functional tests | 18:59 |
| mgedmin | do you know anything about that? | 19:00 |
| * mgedmin is unhappy about faasen introducing a new Person subclass, but doesn't want to start a flamewar | 19:03 | |
| srichter | eek,m etoo | 19:14 |
| srichter | I really do not want a new subclass | 19:14 |
| srichter | let's solve this with annotations. Please!!! | 19:15 |
| th1a|x60s | Well, it is really too late to object. | 19:15 |
| srichter | why? | 19:15 |
| th1a|x60s | Because we don't have time to start over. | 19:15 |
| srichter | we spent all this time last year avoiding double classes | 19:15 |
| srichter | it is just some refactoring | 19:16 |
| srichter | move the custom stuff into an annotation | 19:16 |
| srichter | what was the motivation for the new sub-class? | 19:16 |
| th1a|x60s | I don't want to try to make that argument. | 19:19 |
| srichter | th1a|x60s: This is incredibly silly | 19:19 |
| srichter | for some really trivial data we are creating a new class | 19:19 |
| faassen | look, I shall just give up, okay? | 19:19 |
| faassen | I'm obviously not smart enough to develop schooltool software. | 19:20 |
| faassen | I just had the idea that if an object stores different data, you use a different class. | 19:20 |
| srichter | faassen: no, but we are using annotations | 19:20 |
| srichter | you know that pattern | 19:20 |
| faassen | but in the new world order one uses annotations eveywhere. | 19:20 |
| faassen | as that's the most pythonic approach, right? | 19:20 |
| srichter | well | 19:20 |
| th1a|x60s | One thing I'm trying to avoid here is driving faassen insane. | 19:21 |
| faassen | and if I say it's too slow to pull up a thousand annotations, then I need to show a complete book of profiling results. And guess what, it might even be faster now as when I fisrt prototyped the code, as Jim's branch landed. | 19:21 |
| th1a|x60s | Or, more precisely, make him not want to work on SchoolTool. | 19:21 |
| th1a|x60s | And calling his decisions incredibly silly is not really helpful. | 19:21 |
| faassen | evidently I broke the tests. | 19:21 |
| srichter | ok, I'll retract, but there is really no reason for a subclass | 19:21 |
| srichter | specifically if you are using formlib | 19:21 |
| faassen | look, if you store different data, the oldfashioned pattern in object oriented programming | 19:22 |
| faassen | is to use a new subclass. :) | 19:22 |
| srichter | which does all this adapting to annotations stuff easy for you | 19:22 |
| faassen | look, I started out with annotations. | 19:22 |
| srichter | but component orientation takes a different take on this | 19:22 |
| faassen | I pulled up a table with a couple of hundred of students, or perhaps it was a thousand. | 19:22 |
| faassen | it was rather slow. | 19:22 |
| srichter | it would claim that the address data is meta-data and thus should be in annotations | 19:22 |
| faassen | well, I think that a different school has different person objects altogether. | 19:23 |
| faassen | but I already had this debate a while ago. | 19:23 |
| faassen | I'm just not going to debate this. | 19:23 |
| faassen | we will refactor it later. | 19:23 |
| srichter | btw, I agree with you that we will need a catalog | 19:23 |
| faassen | if you really genuinely think it'll be better. | 19:23 |
| srichter | that will address some of our sissues | 19:23 |
| faassen | but in Python, new data storage is new class. | 19:23 |
| th1a|x60s | I am ok with faassen going ahead with this approach. | 19:24 |
| faassen | I consider annotations for everything as a form of overengineering. | 19:24 |
| srichter | I really believe an annotation is better, but if it stops your progress I retract | 19:24 |
| faassen | now I shall try to unbreak the tests. | 19:24 |
| faassen | hm, appears to be the requirement package. | 19:24 |
| th1a|x60s | This doesn't represent a change in our design strategy. | 19:24 |
| faassen | that got broken. I might've broken it, so I'll check. | 19:24 |
| th1a|x60s | More of an experiment. | 19:24 |
| th1a|x60s | OK? | 19:24 |
| faassen | it's something that can be refactored. but I'm assembling components in Python. | 19:25 |
| faassen | attributes in Python, not in ZCML. :) | 19:25 |
| srichter | fine with me | 19:25 |
| faassen | it's not done yet. | 19:25 |
| srichter | I am justing smelling factory hell down the road | 19:25 |
| th1a|x60s | Yes, it can be undone easily enough. We just can't spend time going in circles right now. | 19:25 |
| faassen | I may switch it to annotations again, I may do something else. | 19:25 |
| faassen | I just don't appreciate the yelling I get constantly. I'm not an idiot. | 19:25 |
| srichter | I was not yelling no CAPS LOCKS :-) | 19:26 |
| th1a|x60s | Well, it came in two waves since srichter was traveling. | 19:26 |
| srichter | oh, I see | 19:26 |
| srichter | I did not get any of the previous discussions | 19:26 |
| th1a|x60s | Right. | 19:26 |
| faassen | and really, I did work with annotations in my sandbox. | 19:27 |
| faassen | and a zc.table that pulls in a thousand annotations was incredibly slow to display. | 19:27 |
| faassen | but who knows, by the time I started putting it into schooltool, the adapter change merged, so the performance is potentially acceptable. it would need more testing. | 19:27 |
| faassen | I shall do a bit more testing later. | 19:27 |
| * srichter apologizes to bring up a soar issue again | 19:28 | |
| th1a|x60s | Sore. | 19:28 |
| * srichter shuts up now and lets people work | 19:28 | |
| srichter | th1a|x60s: thanks | 19:28 |
| faassen | I mean, schooltool development is already making me feel like an idiot. :) | 19:28 |
| faassen | there's rather a lot to think about while doing so. | 19:28 |
| faassen | it doesn't help if people rub it in. :) | 19:28 |
| th1a|x60s | And the fact that faassen finds SchoolTool so difficult makes me fear for the future. | 19:29 |
| faassen | thanks srichter, I understand the response. :) | 19:29 |
| srichter | I agree, ST is something else; he he | 19:29 |
| faassen | I think it's pointing at some underlying issues in Z3 I cannot identify clearly yet. | 19:29 |
| faassen | but there are just too many knobs I need to turn to get something working. | 19:29 |
| faassen | ST has many good things. | 19:29 |
| povbot | /svn/commits: * mg committed revision 6040: | 19:29 |
| povbot | /svn/commits: Remove senseless boolean comparison to true. | 19:29 |
| faassen | it's just something that's in the back of my mind as I do this. | 19:29 |
| faassen | now I apparently broke a test, I want to know how, sorry mgedmin for breaking something. | 19:30 |
| faassen | I just noticed the buildbot was complaining. | 19:30 |
| srichter | ST is a big application, and some of the separation that we desire is not there yet | 19:30 |
| faassen | and reran the tests. | 19:30 |
| faassen | anyway, in some cases it just takes too much ZCML to get something hooked up. | 19:30 |
| srichter | when we have soem air to breathe, we really have to finish the package refactoring | 19:30 |
| faassen | I'm starting to get more and more interested in what we could do with sensible defaults in Zope 3 somehow. | 19:30 |
| mgedmin | faassen: there are two very very simple failures, just click on the build logs in http://source.schooltool.org/buildbot/ | 19:30 |
| faassen | mgedmin: oh, thanks, I didn't realize I could click on those. | 19:31 |
| srichter | faassen: I always write Python doctests first to make sure I feel comfortable with the Python API | 19:31 |
| faassen | I write a lot of python doctests. | 19:31 |
| srichter | if I cannot get or register components effectively while writing the doctest then I consider having an ill API | 19:31 |
| faassen | but you need to do a rather large amount of things just to hook up a new form, say. | 19:31 |
| faassen | concerning security, ZCML, etc. | 19:31 |
| faassen | anyway I can't really express it. | 19:31 |
| faassen | not well yet. | 19:32 |
| faassen | it's not ST so much, though of course that could be rearranged in parts. | 19:32 |
| faassen | part of what I'm trying to do is try to keep my code simple, but that's sometimes hard. :) | 19:32 |
| srichter | yes | 19:32 |
| faassen | anyway, there's a model of customizability I'm thinking about too. | 19:32 |
| faassen | for demographics, each school or country could have its own demographics data. | 19:32 |
| srichter | right | 19:33 |
| faassen | that is not only reflected in the forms | 19:33 |
| faassen | it's also reflected in the way you browse through dat. | 19:33 |
| faassen | data. | 19:33 |
| faassen | and the way you search for data. | 19:33 |
| faassen | if you have a different field in your demographics, you may want to have it in your search form. | 19:33 |
| srichter | right, but quickly you are talking about localization | 19:33 |
| faassen | so more than just the annotations get wired up differently. | 19:33 |
| faassen | well, this is a form of localization that's unrelated to i18n as far as I know. | 19:33 |
| faassen | you'd have localization packages, or school cusomization packages. | 19:33 |
| faassen | that you install into schooltool, and hey, it uses a new form of person object. | 19:34 |
| faassen | that has a different set of annotations at least. | 19:34 |
| faassen | now I think the best way to go about that is with a combination of localization-skins and custom content objects. | 19:34 |
| srichter | btw, I developed some nifty search mechanism for the other project I am doing | 19:34 |
| srichter | I am going to demo it to Tom next week | 19:34 |
| srichter | that might be something to use | 19:34 |
| faassen | not just rewiring annotations, that's not enough, as the table needs to know about it. | 19:34 |
| faassen | that'd be interesting, sure. | 19:34 |
| srichter | it is quiet similar to KMail's message search | 19:35 |
| faassen | anyway, if you can do it with skins and different content objects.. | 19:35 |
| srichter | and I think it fits in our story of keeping searches customizable | 19:35 |
| faassen | you'd be able to install a new customization without having to rewrite any existing ZCML. | 19:35 |
| faassen | you just install the new package, get the new skin, and this makes sure you make the new person objects. | 19:35 |
| faassen | I'm not sure searches need to pluggable. I think customization can be accomplished by a wholesale replacement of the UI, if *making such UI89 is simple enough. | 19:36 |
| faassen | pluggability just invites a lot of complexity. | 19:36 |
| srichter | I;ll let you experiment with it a little bit; I hope it will work out | 19:36 |
| povbot | /svn/commits: * mg committed revision 6041: | 19:36 |
| povbot | /svn/commits: Refactor CalendarEventBookingView a bit. | 19:36 |
| srichter | well, I think you shifted the pluggability from the annotation object to the person object | 19:37 |
| srichter | basically now, in order to stay general, you need to deal with person factories | 19:37 |
| faassen | yes, but annotations require rewriting ZCML. | 19:37 |
| faassen | yes, you'd need to have a pluggable factory, probably. | 19:37 |
| faassen | but mostly that's arranged from the UI. | 19:37 |
| faassen | you just say in your skin, make these persons, not those other ones. | 19:37 |
| faassen | and that allows for you to drive customization from the skinning mechanism. | 19:38 |
| faassen | which I'm more comfortable with than rewriting a lot of ZCML for each school. | 19:38 |
| faassen | I feel rewiring ZCML is brittle. | 19:38 |
| faassen | the one thing that would be hard to do from the skin is the Manager user that gets added initially. | 19:38 |
| faassen | but maybe I'll switch that back to a stupid user. | 19:38 |
| faassen | and make the table code smart enough to just deal with it, don't know. | 19:38 |
| srichter | mmh, that's a good point, Skins allow for a way of overriding configuration that ZCML does not have yet | 19:39 |
| faassen | that's one area where annotations have a benefit. | 19:39 |
| faassen | anyway, I'm not just doing this out of unthinkingness, I'm doing this because I thought about it. I don't know whether this is the right solution. annotations have clear benefits in a number of areas. | 19:39 |
| faassen | so I may go back to them. | 19:39 |
| faassen | but I'm not sure yet. :) | 19:39 |
| srichter | ok, I have not said anything | 19:39 |
| srichter | I am really shutting up now | 19:40 |
| th1a|x60s | I think trying a different approach is worthwhile. | 19:40 |
| povbot | /svn/commits: * faassen committed revision 6042: | 19:43 |
| povbot | /svn/commits: Oops. Should've run all the tests! I made this test for interface instead. | 19:43 |
| faassen | srichter: is there a way to plug factories in Zope 3? | 19:45 |
| faassen | srichter: to say somewhere in ZCML, okay, if you want to make an object of type V, use this factory | 19:45 |
| faassen | srichter: it'd be nice if that could be driven from the skin, even, but that's only doable indirectly. | 19:45 |
| faassen | srichter: I guess you could make a utility | 19:45 |
| faassen | srichter: that has the factory, and just register another one. | 19:45 |
| faassen | srichter: I guess that's a fairly nice model. | 19:46 |
| faassen | srichter: and that worked pretty well for pluggability in zope 2, actually. | 19:46 |
| povbot | /svn/commits: * mg committed revision 6043: | 19:46 |
| povbot | /svn/commits: Slightly more refactoring. Converted a long-standing TODO into actual code. Did not modify the unit test -- I'm a bad bad man. | 19:46 |
| mgedmin | faassen: just making sure -- do you plan to commit the fix for the devmode ftest too? | 19:47 |
| faassen | mgedmin: yes, I just found the problem. | 19:47 |
| faassen | mgedmin: I was trying to find the difference. :) | 19:47 |
| mgedmin | the class name -- person.person.Person vs demographics.person.Person | 19:48 |
| mgedmin | I spent 5 minutes scrolling the diff too | 19:48 |
| mgedmin | up and down, up and down... | 19:48 |
| faassen | mgedmin: yeah, I found it. :) | 19:48 |
| faassen | I guess devmode is legitimately showing the classname. | 19:48 |
| faassen | anyway, perhaps a combination of skin and local utilities is a good way to go for customizability. | 19:49 |
| faassen | mgedmin: sorry I broke those. I should've run all the tests. here I spent all my life waiting for the tests and I don't run them enough after all. :) | 19:50 |
| povbot | /svn/commits: * faassen committed revision 6044: | 19:51 |
| povbot | /svn/commits: Also broke this test due the changeover of the manager user. | 19:51 |
| mgedmin | nah, I think it's ok not to run all the tests all the time if you're pretty sure you didn't break anything, and watch for buildbot notices | 19:53 |
| * mgedmin wonders if he will be sorry he said that | 19:53 | |
| faassen | mgedmin: no, you won't. I'll keep running them all anyway. :) | 19:54 |
| faassen | mgedmin: I usually do, I just forgot this one time. | 19:54 |
| faassen | mgedmin: buildbot is something I am not very familiar with yet, but it's handy. | 19:54 |
| *** thisfred has left #schooltool | 20:00 | |
| povbot | /svn/commits: * faassen committed revision 6045: | 20:35 |
| povbot | /svn/commits: Ripping out person details, as this will be replaced with stuff in the demographics module instead (as per Tom's request). | 20:35 |
| povbot | /svn/commits: Had to adjust devmode again as it was using person details for example functional tests; made it work with PersonPreferences instead. | 20:35 |
| faassen | out of here for today. see you! | 20:35 |
| *** faassen has quit IRC | 20:36 | |
| povbot | /svn/commits: * mg committed revision 6046: | 21:12 |
| povbot | /svn/commits: Fix for issue 486: the user should be able to initially book events if she just has addEvent permission. | 21:12 |
| *** th1a|x60s has quit IRC | 21:31 | |
| povbot | /svn/commits: * mg committed revision 6047: | 21:31 |
| povbot | /svn/commits: Made capitalisation of setup functions consistent (setupFoo -> setUpFoo). | 21:31 |
| *** Aiste has quit IRC | 21:39 | |
| povbot | /svn/commits: * mg committed revision 6048: | 21:47 |
| povbot | /svn/commits: Refactored tests: consolidated multiple EventStub classes. | 21:47 |
| *** mgedmin has quit IRC | 21:52 | |
| povbot | /svn/commits: * alga committed revision 6049: | 21:55 |
| povbot | /svn/commits: Fixed issue454: weekdays in weekly recurring events mess up if the timezone shifts the events to a different date. Also fixed a similar issue with monthly recurring events. | 21:56 |
| *** th1a|x60s has joined #schooltool | 21:59 | |
| *** Aiste has joined #schooltool | 21:59 | |
| *** th1a|x60s has quit IRC | 22:22 | |
| *** th1a|x60s has joined #schooltool | 22:27 | |
| *** th1a|x60s has quit IRC | 22:30 | |
| *** th1a|X60s has joined #schooltool | 22:32 | |
| *** jinty_ has joined #schooltool | 22:48 | |
| *** jinty has quit IRC | 22:48 | |
| *** toxygen has joined #schooltool | 22:57 | |
| toxygen | hi | 22:58 |
| th1a|X60s | toxygen: Hi. | 23:06 |
| *** wrobel has quit IRC | 23:23 | |
| *** wrobel has joined #schooltool | 23:23 | |
| toxygen | jeez, i'm looking forward for beta | 23:36 |
| toxygen | are there any similar project like schooltool? | 23:36 |
| *** jinty_ has quit IRC | 23:38 | |
| *** th1a has joined #schooltool | 23:49 | |
| th1a | Testing GAIM... | 23:50 |
| th1a|X60s | Testing... | 23:50 |
| *** th1a has left #schooltool | 23:51 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!