| *** jstraw has left #schooltool | 00:32 | |
| *** fsufitch has quit IRC | 01:06 | |
| *** jstraw has joined #schooltool | 01:16 | |
| *** jelkner has joined #schooltool | 02:40 | |
| *** jelkner has quit IRC | 03:16 | |
| *** mgedmin has joined #schooltool | 10:01 | |
| *** alga has joined #SchoolTool | 12:43 | |
| *** ignas has joined #schooltool | 14:38 | |
| *** jstraw has quit IRC | 15:11 | |
| *** jelkner has joined #schooltool | 16:03 | |
| *** ignas has quit IRC | 16:11 | |
| *** ignas has joined #schooltool | 16:12 | |
| *** Guest86130 has joined #schooltool | 16:51 | |
| *** Guest86130 has quit IRC | 16:54 | |
| *** replaceafill has joined #schooltool | 17:58 | |
| aelkner | ignas: did you have a chance to read my note about report cards? | 18:10 |
|---|---|---|
| ignas | aelkner: still reading | 18:18 |
| aelkner | ok, thanks | 18:20 |
| *** mgedmin has quit IRC | 19:09 | |
| ignas | hmm, do we need templates? | 19:11 |
| ignas | as in global templates | 19:11 |
| ignas | ok, i guess we do | 19:11 |
| ignas | though I am still not sure what is the best way to do the "i want the same thing in different/terms school years, but i don't want it to change when it's set" | 19:12 |
| ignas | i mean - one way is the way you are planning to do with report card templates | 19:12 |
| ignas | which is - have global templates and populate terms/school years as you go | 19:13 |
| ignas | another way is - set them up in terms/ years | 19:14 |
| ignas | and then add functionality to copy them to the next term/year | 19:14 |
| ignas | as for the hierarchy - I still don't like containers that contain "different" kinds of things | 19:15 |
| ignas | but if you feel that it's better that way - well, it's your choice | 19:15 |
| ignas | for evaluation storage - my advice was doing the refactoring at the same time with activities | 19:16 |
| ignas | and if you move both - activities from section __annotations__ and evaluations from student __annotations__ | 19:16 |
| ignas | you probably would gain more by storing evaluations and activities in the same place | 19:16 |
| ignas | as they are related | 19:16 |
| ignas | the UI side does not depend on the way data is stored in the backend | 19:17 |
| ignas | anyway | 19:17 |
| ignas | as long as you have a class that can pick the data that is needed from the containers and assemble it to provide IGradebook interface | 19:17 |
| ignas | everything works the way it used to | 19:17 |
| ignas | hmm, ok, I have misunderstud the structure that you drew | 19:18 |
| ignas | it only concerns report cards and their templates, not the old gradebook | 19:18 |
| aelkner | ignas: as for the template/deployment idea, it was thla's suggestion, and it sounded fine to me | 19:25 |
| ignas | idea is this | 19:26 |
| ignas | if you put ReportCardsContainer and put one kind of stuff in ['templates'] and a different kind of stuff in ['deployed'] you get a content management system | 19:27 |
| ignas | if you put ReportCards and have attributes templates and deployed | 19:27 |
| ignas | that each are different typed containers for different things - it's data structures | 19:27 |
| ignas | one thing i still don't know is - whether something in gradebook['templates']['template1'] is the same thing that will be in gradebook['deployed'][an int id of a term] | 19:29 |
| aelkner | maybe i didn't use the clearest way of showing my data structure | 19:31 |
| aelkner | but to answer your question | 19:31 |
| aelkner | gradebook['deployed'][an int id of a term]['student1']['activity1]['section1'] | 19:31 |
| ignas | yeah, in understand that | 19:32 |
| ignas | so items in 'deployed' are not copies of templates | 19:32 |
| aelkner | more like distributions i guess | 19:33 |
| aelkner | of course, i would need an event handler for students getting added/removed from sections | 19:34 |
| ignas | well - i think schooltool.gradebook is not handling that | 19:34 |
| ignas | if you remove sutdents or sections - evaluations stay where they are | 19:34 |
| aelkner | you mean currently? | 19:34 |
| ignas | yeah | 19:34 |
| aelkner | yeah, that's true | 19:35 |
| ignas | and that has some kind of special meaning as in - we don't want data entered into the system disappear as it is too important | 19:35 |
| ignas | or something like that | 19:35 |
| ignas | though - imho if it's important - make backups | 19:35 |
| aelkner | yeah, an example of the benefit of the way evaluations currently work | 19:35 |
| ignas | making backups inside of ZODB does not make much sense | 19:35 |
| aelkner | when cando had problems with sections | 19:36 |
| aelkner | when the inheritance problem caused the assigned comps to crash the system | 19:36 |
| aelkner | dwelsh was able to remove all sections and recreate them | 19:36 |
| aelkner | and magically the evaluations were still there | 19:37 |
| ignas | strange, because I think evaluations are stored not using section_id | 19:37 |
| aelkner | after he recreated the comp assignment | 19:37 |
| aelkner | right, they're store using the competency id | 19:37 |
| aelkner | in the annotation of the student | 19:37 |
| ignas | ahh, you retained competency_ids | 19:37 |
| ignas | and competencies were not removed together with sections | 19:38 |
| aelkner | right, sections were only refering to the comps | 19:38 |
| ignas | as for structures in | 19:38 |
| ignas | GradebookReportCards.deployed['term_int_id'] | 19:39 |
| ignas | i'd suggest | 19:39 |
| ignas | GradebookReportCards.deployed['term_int_id']['activity']['student']['section'] | 19:39 |
| ignas | hmm, ok, maybe I am wrong again | 19:39 |
| ignas | your primary reports will be: | 19:39 |
| ignas | section based | 19:39 |
| ignas | student based | 19:40 |
| aelkner | student based | 19:40 |
| ignas | and entry - section based | 19:40 |
| aelkner | no, also student based | 19:40 |
| ignas | reallt? | 19:40 |
| ignas | so teacher will go to the report cards | 19:40 |
| aelkner | remember, the gradebook rows are sections for he student | 19:40 |
| ignas | and go through every student separately | 19:40 |
| ignas | i am assuming that teachers want to see "all the students for his section" (section based) | 19:41 |
| aelkner | you make a good point | 19:41 |
| ignas | and students "all the sections for them" (student based) | 19:41 |
| aelkner | i think thla needs to way in on how data entry should work | 19:41 |
| aelkner | but i think you're right about having the all students for this section view | 19:42 |
| ignas | it might be useful to have a double key of some kind | 19:42 |
| aelkner | explain | 19:42 |
| ignas | like ['term_int_id']['student', 'section'] | 19:43 |
| aelkner | ah | 19:43 |
| ignas | otoh - that does not change the way you access data much | 19:43 |
| ignas | you still would have problems iterating finding all the evaluations for a specific section | 19:43 |
| ignas | so you'd either "get all members" => "get all evaluations for each member + section" | 19:44 |
| ignas | or "get all sections" => "get all evaluations for each section + student" | 19:44 |
| ignas | activity being the root makes it more difficult | 19:44 |
| ignas | so either a section or a student must be the "top one" | 19:44 |
| ignas | and activity must be the last level | 19:45 |
| ignas | should be | 19:45 |
| aelkner | i agree with that | 19:45 |
| ignas | or else you have to do (with the schema that you drew) | 19:45 |
| ignas | for student in section: for activity in IReportCardEvaluations(student).activities(): for some_section in activity: if some_section == section: "get the grade" | 19:46 |
| ignas | and you want it reduced to at least | 19:46 |
| ignas | for stedent in section: for activity in IReportCardEvaluations(student)[section.__name__]: "get the grade" | 19:47 |
| ignas | or something close to that | 19:47 |
| ignas | you can hide most of it under ISectionReportCardEvaluations() and IStudentReportCardEvaluations() and change it later if it's too slow or for whatever other reason you have | 19:48 |
| ignas | well, all I can suggest is - write a lot of functional tests so you can fix stuff when it breaks later | 19:49 |
| ignas | because it will, the task is pretty complicated ;) | 19:49 |
| ignas | for anyone | 19:49 |
| aelkner | see, i think that the heirarchy of containers makes the task the simplest | 19:50 |
| aelkner | like when i wrote the intervention system | 19:50 |
| ignas | nope | 19:50 |
| aelkner | after the heirarchy was worked aout | 19:50 |
| ignas | well kind of | 19:50 |
| ignas | you are using hierarchy in one place for the tight hting | 19:51 |
| ignas | in another place for the wrong thing | 19:51 |
| aelkner | the task of writing it was not too complicated | 19:51 |
| ignas | the [term_id][section_id][student_id] | 19:51 |
| ignas | is the right part of it | 19:51 |
| ignas | as everything under different term ids is "ISomething" | 19:51 |
| ignas | and everything under section_id is "ISomethingElse" | 19:51 |
| ignas | and everything under [student_id] is IEvaluationContainer or whatever | 19:52 |
| ignas | while app['schooltool.gradebook.reports'] contains | 19:52 |
| ignas | "IContainer" thingies | 19:52 |
| ignas | maybe | 19:52 |
| aelkner | what did you just say? | 19:53 |
| ignas | not sure if we are even discussing the same thing ;) | 19:53 |
| aelkner | no, i thnk we are | 19:53 |
| aelkner | we're talking about containers of containers, etc. | 19:53 |
| aelkner | i said how that make it easy | 19:54 |
| ignas | yeah | 19:54 |
| ignas | yeah | 19:54 |
| aelkner | it's like a file system | 19:54 |
| aelkner | easy to traverse | 19:54 |
| ignas | now that's the problem | 19:54 |
| ignas | no | 19:54 |
| ignas | this is application | 19:54 |
| ignas | not file system | 19:54 |
| ignas | not content management system | 19:54 |
| aelkner | you're talking compsci theory | 19:54 |
| aelkner | application vrs CMS | 19:55 |
| ignas | comp sci does not teach that | 19:55 |
| ignas | use containers like lists and dicts, you don't want to put different kinds of things in the same container | 19:55 |
| ignas | unless you are reimplementing a file system | 19:55 |
| ignas | or programming a CMS ;) | 19:55 |
| aelkner | i'm not, i'm putting caontiners in containers | 19:55 |
| ignas | IContainer is too abstract | 19:55 |
| ignas | which is why we have | 19:55 |
| ignas | PersonContainer | 19:55 |
| ignas | and CourseContainer | 19:56 |
| ignas | not BTreeContainer instances | 19:56 |
| ignas | so we define that CourseContainer contains(ICourse) | 19:56 |
| ignas | and CourseCourseContainer contains(ICourseContainer) | 19:56 |
| aelkner | well, this is why i asked for your suggestions | 19:57 |
| aelkner | but instead of just saying my idea is wrong | 19:57 |
| ignas | i am not saying your idea is wrong | 19:57 |
| aelkner | could you come up with a counter-proposal | 19:57 |
| ignas | only the first step is the part i don't like | 19:58 |
| ignas | and I have suggesteds | 19:58 |
| ignas | having an object with 2 attributes | 19:58 |
| ignas | templates | 19:58 |
| ignas | and deployed | 19:58 |
| aelkner | of what type? | 19:58 |
| ignas | instead of a BTreeContainer | 19:58 |
| ignas | each of those will be Containers of some kind | 19:58 |
| ignas | ReportTemplateContainer | 19:58 |
| ignas | and ReportEvaluationContainer for example | 19:59 |
| ignas | and from there - it's containers all the way ;) | 19:59 |
| aelkner | i see | 19:59 |
| aelkner | i just realized something | 20:00 |
| aelkner | evaluations are currently annotations | 20:00 |
| aelkner | using the keyref of the activity as the key | 20:00 |
| aelkner | what i mean is | 20:00 |
| aelkner | the worksheets that are annotated on the sections | 20:01 |
| aelkner | contain the activities | 20:01 |
| aelkner | so the heirarchy of the activities within the worksheets is stored in one place | 20:01 |
| aelkner | and the evaluations (again annotated on the student object) | 20:01 |
| ignas | yeah | 20:02 |
| aelkner | are stored by referring to the activities | 20:02 |
| aelkner | so my email was wrong | 20:02 |
| aelkner | when i deply the template | 20:02 |
| ignas | i have mentioned that i do it differently in lyceum.journal when you were driving ;) | 20:02 |
| aelkner | i need to copy the heirachy to one place | 20:02 |
| ignas | as it is easier to keep evaluations at the same place with the activities | 20:02 |
| aelkner | and i need a different heirachy for storing the evaluations | 20:02 |
| ignas | yeah, seems so | 20:03 |
| aelkner | i forgot about that point you made | 20:03 |
| aelkner | i guess i was trying not to crash :) | 20:03 |
| ignas | nah, you were trying not to cross the Patomac | 20:04 |
| aelkner | right, that was is | 20:04 |
| aelkner | it | 20:04 |
| ignas | ok, i must go home now, guess you have things to think about ;) | 20:04 |
| aelkner | you think? :) | 20:04 |
| ignas | hope, rather ;) | 20:05 |
| aelkner | are you gone for the weekend? | 20:05 |
| ignas | saturday is a work day here | 20:05 |
| aelkner | oh, cool, i'll see you then | 20:05 |
| ignas | bye | 20:07 |
| *** ignas has quit IRC | 20:07 | |
| *** replaceafill has quit IRC | 20:08 | |
| *** alga has quit IRC | 20:33 | |
| *** jstraw has joined #schooltool | 20:57 | |
| *** jcrowley has joined #schooltool | 21:18 | |
| *** elarson has joined #schooltool | 21:29 | |
| *** jelkner has quit IRC | 22:05 | |
| *** elarson has quit IRC | 22:05 | |
| *** jcrowley has quit IRC | 22:08 | |
| *** jstraw has quit IRC | 23:17 | |
| *** replaceafill has joined #schooltool | 23:34 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!