| *** alga has joined #SchoolTool | 00:04 | |
| *** replaceafill has quit IRC | 01:31 | |
| *** jstraw has joined #schooltool | 01:48 | |
| *** jstraw1 has joined #schooltool | 03:03 | |
| *** jstraw has quit IRC | 03:03 | |
| *** jstraw1 has quit IRC | 03:04 | |
| *** jstraw has joined #schooltool | 03:04 | |
| *** jstraw has quit IRC | 03:08 | |
| *** jstraw has joined #schooltool | 03:18 | |
| *** jstraw1 has joined #schooltool | 03:47 | |
| *** jstraw has quit IRC | 03:47 | |
| *** alga has quit IRC | 03:59 | |
| *** jstraw1 has quit IRC | 04:11 | |
| *** fsufitch has joined #schooltool | 04:26 | |
| *** aelkner has quit IRC | 04:34 | |
| *** aelkner has joined #schooltool | 04:37 | |
| *** jstraw has joined #schooltool | 04:51 | |
| *** ignas has joined #schooltool | 12:07 | |
| *** alga has joined #SchoolTool | 13:21 | |
| *** fsufitch has quit IRC | 14:15 | |
| aelkner | ignas: ayt? | 17:51 |
|---|---|---|
| ignas | yeah | 17:51 |
| aelkner | so i was thinking about your objection to having different types of containers in a container | 17:51 |
| aelkner | like i did with app['schooltool.interventions'][2008-2009']['messages'] vrs ['goals'], etc. | 17:52 |
| aelkner | and what i was suggesting in my note with ...['templates'] and ['deployed'] and ['evaluations'] | 17:53 |
| aelkner | but consider this | 17:53 |
| aelkner | the app root itself is a container that contains diefferent types of containers | 17:53 |
| aelkner | like persons, schoolyears, etc | 17:54 |
| aelkner | so i'm not getting the harm in that | 17:54 |
| aelkner | wouldn't you say it's inconsistent to worry about it in one place and not another? | 17:56 |
| aelkner | another thing | 17:57 |
| ignas | there is a reason why we did that with app | 17:57 |
| ignas | and it was done 3 years ago | 17:57 |
| aelkner | yes? | 17:58 |
| ignas | back then the idea was - "we want to make it extensible, so let's make app a container" | 17:58 |
| aelkner | right | 17:58 |
| ignas | so other people could add their own "stuff" in there | 17:58 |
| ignas | also - we did not have pluggable traversers | 17:58 |
| ignas | so making traversal into an attribute possible would have required editing SchoolToolApplication code | 17:59 |
| ignas | or so we thought | 17:59 |
| ignas | also - i think this idea came to be before we used full Zope3 even | 17:59 |
| ignas | and also that is one of the reasons why I prefer ISchoolYearContainer(app) over app['schooltool.schoolyear'] | 18:00 |
| ignas | because you have some sort of contract | 18:00 |
| ignas | saying - give me this thing | 18:00 |
| ignas | instead of "give me anything that's there" | 18:00 |
| aelkner | so you're saying that if you could do it from scratch, app wouldn't be a container | 18:01 |
| ignas | it probably would be, because it is a root object, and you can't have multiple roots in a straightforward way | 18:02 |
| ignas | while in your case anyone without access to gradebook code but still wanting to add some stuff - can just add app['ignas.gradebook'] | 18:02 |
| aelkner | yeah, the container makes extending it and easy thing to do | 18:03 |
| ignas | but while it's neccessary for application to have different "modules", i don't think gradebook needs "modules" inside of it | 18:05 |
| aelkner | well, if we already had app['schooltool.gradebook'].activities, where we kept the activities | 18:05 |
| aelkner | instead of as annotations as they are now | 18:05 |
| aelkner | and we already had app['schooltool.gradebook'].evaluations where we had the evaluations | 18:06 |
| aelkner | now i'm coming along and, as you suggest, i would add .templates and .deployed | 18:06 |
| ignas | you are not coming along | 18:06 |
| ignas | you are changing the gradebook itself | 18:06 |
| ignas | schoooltool.gradebook | 18:07 |
| aelkner | but what i'm saying is i'm adding attributes to that object | 18:07 |
| ignas | yeah | 18:07 |
| aelkner | remember how you said by putting initialization of class attribute in BasicPerson | 18:08 |
| ignas | not in this case | 18:08 |
| ignas | you can do that with strings | 18:08 |
| ignas | and with None | 18:08 |
| ignas | if you want an instance of a persistent object there | 18:08 |
| ignas | you do evolution | 18:08 |
| aelkner | so you see how much of a pain it is to update the code | 18:09 |
| aelkner | you need to evolve in order to do it | 18:09 |
| ignas | it'd be a 3-4 line script anyway | 18:09 |
| ignas | and if you have a container | 18:09 |
| ignas | you'd either have to use "write on read" | 18:09 |
| ignas | which is not a very nice thing to do and also adds 3-4 lines of code | 18:09 |
| ignas | or - an evolution script | 18:09 |
| ignas | and even then - you can do write on read with attributes too (probably should not) | 18:10 |
| ignas | how else do you think of populating app['schooltool.gradebook']['templates'] with a template container? | 18:11 |
| aelkner | like i did with the intervention system, write on read | 18:12 |
| aelkner | you see i like write on read | 18:12 |
| aelkner | because the code can handle any state of the db | 18:12 |
| aelkner | whereas evolution scripts force us to think about the state of the db at any given time | 18:12 |
| ignas | any? | 18:12 |
| aelkner | that will become more and more complicated as the app grows | 18:13 |
| ignas | any? | 18:13 |
| ignas | not really | 18:13 |
| ignas | only the state that is now matters | 18:13 |
| ignas | that's their beauty | 18:13 |
| ignas | i mean - you get all the app things, and do app['schooltool.gradebook'].templates = TemplateContainer() | 18:13 |
| ignas | and that's it | 18:14 |
| aelkner | you're talking about what the evolution script would do, right? | 18:14 |
| ignas | yeah | 18:14 |
| aelkner | heck, the first evolution script i need to write would need to create app['schooltool.gradebook'] in the first place | 18:16 |
| ignas | ahhh | 18:16 |
| ignas | so there are no schooltool.gradebook's at the moment? | 18:16 |
| ignas | or "there might not be any?" | 18:16 |
| aelkner | everything is in annotations | 18:16 |
| ignas | if there are not any of them | 18:16 |
| ignas | then you just create the attributes | 18:17 |
| ignas | in the constructor of the Gradebook object | 18:17 |
| ignas | and create that object using write on read | 18:17 |
| ignas | in app['schooltool.gradebook'] | 18:18 |
| ignas | no evolution neccessary | 18:18 |
| aelkner | so let me restate what i think you're saying | 18:18 |
| aelkner | for now I make ISchooltoolGradebook(app) be a write on read adapter | 18:19 |
| aelkner | and the constructor for SchooltoolGradebook, the object, would create the attributes templates, deployed, evalutations, etc. | 18:19 |
| ignas | yeah | 18:20 |
| aelkner | and not evolution is necessary | 18:20 |
| ignas | yes | 18:20 |
| ignas | because there is no object to evolve | 18:20 |
| aelkner | if in the future we need to add another attribute to SchooltoolGradebok | 18:20 |
| ignas | there was no object in there before | 18:20 |
| aelkner | we would need evolution at that time | 18:20 |
| ignas | yes | 18:20 |
| ignas | but you'd need it anyway, unless you'd add one more level of indirection | 18:20 |
| ignas | that could do write on read | 18:21 |
| ignas | like IGradebookTemplates(ISchoolToolGradebook(app)) | 18:21 |
| aelkner | well, that's what i'm getting at | 18:21 |
| ignas | or IGradebookTemplates(app) | 18:21 |
| aelkner | if write on read is an exceptable strategy | 18:21 |
| ignas | acceptable? | 18:21 |
| ignas | in the case of a top level container - i think yes | 18:22 |
| ignas | because gradebook is a plugin | 18:22 |
| ignas | so - you can get from "no gradebook" to "with gradebook" without zope running any evolution scripts at all | 18:22 |
| ignas | so you both - don't do evolution, and also - don't have to do AppInit stuff | 18:22 |
| aelkner | that's what i love about it | 18:23 |
| ignas | which is a good tradeoff in this case - you do write on read, you get it be a plugin | 18:23 |
| ignas | but you see - dealing with options of "there is gradebook" and "there is no gradebook" when thinking about the db is easier | 18:23 |
| ignas | than thinking about "there is gradebook that has templates and evaluations" vs "there is gradebook that has activities" | 18:24 |
| aelkner | easier than? | 18:24 |
| aelkner | how so? | 18:24 |
| ignas | because there are 2 possible choices | 18:24 |
| ignas | vs 16 (with 4 containers that might be there) | 18:24 |
| aelkner | 2 vrs 16, they are both more than one | 18:25 |
| aelkner | once an idea works for 1 and n+1, it works for all | 18:26 |
| aelkner | as in mathematical induction | 18:26 |
| aelkner | i'm telling you, i love write on read | 18:26 |
| ignas | :D | 18:27 |
| aelkner | and i don't know why we could apply it as a rule rather than only in some places | 18:27 |
| aelkner | it's either a mistake to do it at all | 18:28 |
| aelkner | or it's a good idea | 18:28 |
| aelkner | so why not do it everywhere | 18:28 |
| ignas | when all you have is a hammer, every problem looks like a nail | 18:28 |
| ignas | it's a fallacy, some tools are good in some places and are not good in other places | 18:28 |
| aelkner | you could put it another way | 18:30 |
| aelkner | if a hammer for all problems | 18:30 |
| aelkner | then you're tool belt doesn't need to be as heavy | 18:30 |
| alga | aelkner: are you saying that maintaining 16 cars in a family is as hard as maintaining 2? :) | 18:30 |
| aelkner | actually i'm saying if you have mechanic in the family | 18:31 |
| aelkner | then maintaining 16 cars is not any harder than 2 :) | 18:31 |
| ignas | my head can only fit 7 variables in it at once, once it goes past 7 - all bets are off, and i will forget something | 18:32 |
| aelkner | for me it's more like 3 varaibles | 18:32 |
| aelkner | but it's not like one needs to keep it in one's head | 18:32 |
| aelkner | the code takes care of ot | 18:32 |
| aelkner | it | 18:32 |
| ignas | yes, I need when writing evolution scripts | 18:32 |
| aelkner | ah, i see | 18:33 |
| ignas | because I can't entrust that to adapters, i must know what parts of the system can be there and what - can not be there, and handle each such place | 18:33 |
| ignas | so later I will have a gradebook object, and well - have no idea what's in it, because maybe someone looked at activity list and activity container got created, maybe not | 18:34 |
| ignas | maybe some one just added a template, and so initialized templates and deployed, but maybe not | 18:34 |
| ignas | I can handle "is there a gradebook - if yes - evolve it" | 18:35 |
| ignas | kind of easily, but doing gradebook['templates'].updateTemplates() | 18:35 |
| ignas | releasing | 18:35 |
| ignas | and then saying Oops, we just broke 3 installations, because I forgot that templates can be uninitialized | 18:35 |
| ignas | just unittesting the code that has to handle it technically requires you to recreate all possible states of the object | 18:36 |
| ignas | it's easier when you don't have to find all the possible states by grepping for write on read adapters ;) | 18:37 |
| aelkner | it's a good point | 18:37 |
| aelkner | you always win when you start talking complexity of evolution scripts :) | 18:37 |
| jstraw | round 2! fight?! :) | 18:42 |
| ignas | jstraw: how is polishing startup scripts and packaging them into debian packages going? | 18:43 |
| jstraw | uh not far... | 18:43 |
| jstraw | I had a mess on my hands last week | 18:43 |
| jstraw | Moodle upgrade for the loss | 18:43 |
| * ignas kidding ;) it's like beating up the announcer during a box match ;) | 18:43 | |
| jstraw | that said... it is on my list of things to do | 18:44 |
| jstraw | *unrolls a scroll with 30 feet of things to do* | 18:44 |
| ignas | :) | 18:45 |
| aelkner | ignas: given that I eventually want to move the existing annotations of section and person to app['schooltool.gradebook'] | 18:52 |
| aelkner | could it be a good strategy for me to write that evolution script first | 18:52 |
| aelkner | and have it create app['schooltool.gradebook'] there | 18:53 |
| aelkner | then i wouldn't even need write on read | 18:53 |
| aelkner | and i'd only have the one evolution script to write | 18:53 |
| aelkner | once again trying to use less tools rather than more | 18:53 |
| ignas | hmm, does schooltool.gradebook have it's own evolution scripts? | 18:58 |
| aelkner | not yet, but i cold add it | 18:58 |
| ignas | you do know that you must first deploy the "0" evolution script | 18:58 |
| ignas | and you can only continue evolving after that | 18:59 |
| ignas | so if you will simply add 1 evolution script for schooltool.gradebook | 18:59 |
| ignas | it will not get run | 18:59 |
| ignas | a nasty feature | 18:59 |
| ignas | but the logic is that - evolution scripts don't know whether "you have not run script 1" vs "you have installed the plugin/app for the first time" | 19:00 |
| ignas | you can work around this by writing an "installable" evolution script, but that is also tricky | 19:01 |
| * ignas still hasn't got the full schooltool plugin evolution workflow properly ready | 19:01 | |
| ignas | not sure if i can make something up for this release | 19:02 |
| ignas | ok, going home | 19:09 |
| ignas | bye | 19:09 |
| *** ignas has quit IRC | 19:09 | |
| *** alga has quit IRC | 19:30 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!