| th1a_ | Anyhow, generally, when the term ends, you want to allow a period of time for grades to be calculated, and then lock the records. | 00:00 |
|---|---|---|
| ignas | these are not affected by the things i am going to do | 00:01 |
| th1a_ | OK. | 00:01 |
| ignas | i mean it's up to the gradebook to decide | 00:01 |
| ignas | how to react to the term ending | 00:01 |
| th1a_ | Yes, that's the gradebook's problem. | 00:01 |
| ignas | most probably old code using sections, timetables, groups and persons will still work | 00:02 |
| th1a_ | Well, that's good. | 00:03 |
| ignas | just that such code will not be paying attention to the history of these objects | 00:04 |
| ignas | thus will only see the current state | 00:04 |
| th1a_ | That makes sense. | 00:04 |
| ignas | what i am mostly worried about is - permissions and access control | 00:04 |
| ignas | it is quite difficult to think aobut them while taking the past into account | 00:05 |
| *** jhancock__ has joined #schooltool | 00:05 | |
| th1a_ | In general, your ability to change the past should be limited. | 00:06 |
| ignas | not just change | 00:06 |
| ignas | just the usecase of "you were a teacher of a section for 2 months" | 00:06 |
| ignas | vs " you were the last person teaching this section" | 00:07 |
| th1a_ | Well, hm. | 00:07 |
| th1a_ | Changing the teacher of a section is just inherently messy. | 00:08 |
| ignas | i will probably stick to relationships that were during the last day of the term/school year objects belonged to | 00:08 |
| th1a_ | I mean, the business practices for changing the teacher of a section are very unclear. | 00:08 |
| ignas | members are fishy too, like - if you were a member of a section for 4 monthes, and then you got removed from it | 00:09 |
| ignas | you sohuld be able to see at least some data | 00:09 |
| ignas | related to that period of time | 00:09 |
| ignas | like your gradebook | 00:09 |
| ignas | for that subject | 00:09 |
| th1a_ | I think in practice the solutions to the individual cases aren't that hard. | 00:09 |
| ignas | i hope so | 00:10 |
| ignas | do we have any other choice? | 00:10 |
| th1a_ | Insofar as, if you were ever in the section, you can probably safely see everything in the section you would be able to if you were still in it. | 00:10 |
| th1a_ | Being able to see what assignments you're not doing isn't a big deal, for example. | 00:11 |
| ignas | indeed | 00:11 |
| th1a_ | I mean, SchoolTool will have to be able to say two things. | 00:12 |
| th1a_ | Are you in this course now? | 00:12 |
| th1a_ | Were you ever in this course? | 00:12 |
| th1a_ | If you withdrew, when? | 00:12 |
| th1a_ | (three) | 00:12 |
| ignas | a new set of crowds i guess | 00:12 |
| ignas | TeachersCrowd and an ExTeachersCrowd | 00:12 |
| th1a_ | OK, I vote for not removing teachers from sections. | 00:13 |
| th1a_ | If the teachers change, you've got two teachers. | 00:13 |
| *** didymo has joined #schooltool | 00:14 | |
| ignas | doing these two and tracking them is not too difficult, it's the concept of your role flowing and changing during the lifetime of the system | 00:14 |
| th1a_ | In practice, that transition is unlikely to be clean. | 00:14 |
| th1a_ | Here's another use case though: substitute teachers. | 00:15 |
| th1a_ | You need to give them a temporary login and let them take attendance or grade in the place of the main teacher. | 00:15 |
| ignas | hmm, i guess it is easier to make him a normal teacher, and then disable his user, though i don't really know how things will turn out at the moment | 00:16 |
| ignas | it might be quite easy | 00:16 |
| th1a_ | Well, it is also the kind of case where it is easier if you aren't doing super-anal legally binding in the US attendance tracking. | 00:17 |
| ignas | :) | 00:18 |
| ignas | actually attaching sections to terms and tracking their members during the term will make it possible to do some weird things | 00:19 |
| th1a_ | But the substitute case is a good one for having some system for making someone a teacher of a section for a limited period of time. | 00:19 |
| th1a_ | Good weird or bad weird? | 00:19 |
| ignas | like - having members of a section change, while changing time for lessons sometimes while everything is working together | 00:20 |
| ignas | good weird | 00:20 |
| ignas | i have tried to make implementing the modifiable timetabling as easy as possible | 00:20 |
| ignas | though it requires looking at schooltool from a strange perspective | 00:21 |
| ignas | (have you ever worked with 2d/3d animation software?) | 00:21 |
| *** jhancock_ has quit IRC | 00:22 | |
| th1a_ | A little. | 00:23 |
| ignas | you know the concept of keyframes | 00:24 |
| th1a_ | Yes. | 00:24 |
| th1a_ | I think I see where you're going. | 00:24 |
| ignas | so the idea is having school years and Terms define the timeline | 00:24 |
| ignas | with discrete slots | 00:24 |
| ignas | school days | 00:24 |
| ignas | while sections are storing their state (if it changes) in any of the slots that exists in the related timeline | 00:25 |
| ignas | so you can modify the first keyframe to change the object for the whole term | 00:25 |
| ignas | you can add "keyframes" that add/remove members | 00:25 |
| ignas | you can later modify them even | 00:25 |
| ignas | while the system can get a consistent state of the object by passing a schoolday that it cares about | 00:26 |
| th1a_ | Yes. | 00:27 |
| ignas | so making lessons during some school day 5 minutes schorter just adds 2 "keyframes" | 00:27 |
| ignas | one that changes the timetable schema to a compatible one with different period lengths, and another one that switches it back | 00:27 |
| ignas | it's quite strange, but some things are moving towards the design that you and Stephan worked on | 00:29 |
| ignas | well not strange ;) | 00:29 |
| ignas | a lot of the ideas were really good | 00:29 |
| th1a_ | Well, it is simpler if you don't have to also think about wfmc. | 00:29 |
| ignas | :) | 00:29 |
| th1a_ | Just take out the shiny new hammer. | 00:30 |
| th1a_ | That is, remove the shiny hammer. | 00:31 |
| ignas | hammer is dead, long live the hammer ;) | 00:32 |
| *** jhancock__ has quit IRC | 00:36 | |
| *** jhancock_ has joined #schooltool | 00:39 | |
| *** ignas has quit IRC | 01:32 | |
| *** kkubasik_ has joined #schooltool | 03:21 | |
| *** kkubasik has joined #schooltool | 03:21 | |
| *** kkubasik__ has joined #schooltool | 03:23 | |
| *** kkubasik__ has quit IRC | 03:24 | |
| *** kkubasik_ has quit IRC | 03:40 | |
| *** jhancock_ has quit IRC | 04:16 | |
| *** Fujitsu_ has joined #schooltool | 04:23 | |
| *** Fujitsu has quit IRC | 04:23 | |
| *** Fujitsu_ is now known as Fujitsu | 04:58 | |
| *** alga has quit IRC | 05:56 | |
| *** didymo has quit IRC | 06:18 | |
| *** subir has joined #schooltool | 08:28 | |
| *** mgedmin has joined #schooltool | 12:18 | |
| *** Aiste has quit IRC | 13:28 | |
| *** subir has quit IRC | 13:35 | |
| *** alga has joined #SchoolTool | 14:42 | |
| *** kkubasik has quit IRC | 15:35 | |
| *** th1a has joined #schooltool | 15:39 | |
| *** alga has quit IRC | 15:39 | |
| *** ignas has joined #schooltool | 16:03 | |
| *** aelkner has joined #schooltool | 16:12 | |
| ignas | aelkner: hi | 16:16 |
| aelkner | hey there | 16:16 |
| aelkner | i did a lot of reading last night on relationships | 16:16 |
| aelkner | i had avoided that code for some time as i didn't need to understand it | 16:16 |
| aelkner | but now with the section issues, i do | 16:16 |
| aelkner | so i get how LinkSets are added to object's annotations | 16:17 |
| aelkner | i'm currently trying to figure out how RelationshipProperty can be used as a lsit | 16:18 |
| aelkner | i'm guessing there's some magic wtht he __get__ method | 16:18 |
| aelkner | that causes it to be a list | 16:18 |
| aelkner | but i need to read up on __get__ which i'm doing now | 16:18 |
| *** alga has joined #SchoolTool | 16:18 | |
| th1a | hey aelkner, ignas. | 16:23 |
| aelkner | hry Tom | 16:23 |
| aelkner | i was telling ignas that i'm having trouble figuring out how a RelationShipProperty becomes a list | 16:24 |
| aelkner | but i guess that's not important for the discussion of terms | 16:24 |
| th1a | Yes, I can see what you were talking about ;-) | 16:25 |
| aelkner | reading the python docs on __get_ is not helping yet. | 16:25 |
| aelkner | very confusing | 16:25 |
| ignas | aelkner: isn't __iter__ the part that does the list stuff | 16:26 |
| aelkner | it alwasys does | 16:26 |
| ignas | and __getitem__ | 16:26 |
| ignas | if you want the direct access to some element in the list | 16:26 |
| aelkner | but RelationshipProperty doesn't have that | 16:26 |
| aelkner | it just has this __get__ method | 16:26 |
| ignas | oh | 16:27 |
| ignas | yep, RelationshipProperty is a descriptor | 16:27 |
| aelkner | BoundRelationshipProperty has __iter__ | 16:27 |
| aelkner | so it's just a matter of understanding what it means to bind | 16:27 |
| aelkner | perhaps when one goes for the __iter__ of a RalationshipProperty object | 16:28 |
| aelkner | it results in finding the __iter__ for a BoundRelationshipProperty object | 16:28 |
| ignas | not really | 16:28 |
| ignas | rather when you access foo.members | 16:29 |
| ignas | instead of getting RelationshipProperty | 16:29 |
| ignas | you get the BoundRelationship property | 16:29 |
| ignas | bound to the instance | 16:29 |
| mgedmin | aah, descriptors | 16:29 |
| ignas | (RelationshipProperty was created in the class) | 16:29 |
| ignas | aelkner: http://video.google.com/videoplay?docid=7760178035196894549 - Advanced Python | 16:30 |
| ignas | watch this | 16:30 |
| aelkner | watching... | 16:31 |
| th1a_ | I just hit you with a load of blueprint spam. | 16:42 |
| th1a_ | That must be a long video. | 17:16 |
| ignas | yes | 17:19 |
| ignas | 1 hour or so | 17:19 |
| th1a_ | Ah. | 17:20 |
| ignas | it's worth it | 17:21 |
| ignas | ;) | 17:21 |
| *** jelkner has joined #schooltool | 17:33 | |
| th1a_ | jelkner: I had one comment on your blueprints. | 17:37 |
| th1a_ | Which I'm sure you would have preferred to have before yesterday. | 17:38 |
| aelkner | ignas: i watched the video, and it's one of those things that i think takes repeated viewings to understand fully | 17:51 |
| aelkner | perhaps other references would help, too | 17:51 |
| aelkner | mainly, he talks breifly about concepts | 17:52 |
| aelkner | but he doesn't go into detailed examples | 17:52 |
| aelkner | which is where i usualyy gain understanding | 17:52 |
| aelkner | but i saved it away for future viewing | 17:52 |
| aelkner | ignas: are you there? | 17:53 |
| ignas | yes | 17:53 |
| ignas | a sec | 17:53 |
| aelkner | when you are ready could you please verify or deny the following: | 17:54 |
| aelkner | in section for example | 17:54 |
| aelkner | when someone says mysection.members | 17:54 |
| aelkner | even though members is defined as a RelationshipProperty | 17:55 |
| aelkner | which has no __iter__ | 17:55 |
| aelkner | they will get the __iter__ for the BoundRElationshipProperty class | 17:55 |
| aelkner | In other words RElationshipProperty is a desriptor of BoundRelationshipPeroperty | 17:56 |
| aelkner | but even saying that, i'm not sure what i mean | 17:56 |
| aelkner | but am i on the right track? | 17:56 |
| ignas | not the __iter__, they will get the BoundRelationshipProperty itself | 17:57 |
| aelkner | mysection.members,__iter__ i meant | 17:57 |
| aelkner | mysection.members.__iter__ i meant | 17:58 |
| ignas | the "mysection.members" is | 17:58 |
| ignas | not RelationshipProperty | 17:58 |
| ignas | but rather a BoundRelationshipProperty | 17:58 |
| ignas | while mysection.__dict__['members'] is a RelationshipProperty | 17:58 |
| ignas | so mysection.members retrieves RelationshipProperty from the __dict__, then sees that it has an __get__ method | 17:59 |
| ignas | and calls it | 17:59 |
| ignas | which yields a BoundRelationshipProperty object | 17:59 |
| ignas | that you see when you look at mysection.members | 17:59 |
| aelkner | i noticed that in pdb once | 18:00 |
| aelkner | saving mysection.mebers yielded <BoundRelat... > | 18:00 |
| aelkner | so I think i get it now | 18:00 |
| aelkner | but i'm not quite sure why we need RelationshipProperty | 18:01 |
| aelkner | if instance is None | 18:01 |
| aelkner | why would that be true? | 18:01 |
| aelkner | is it for when someone wants to look at members as a class attribute when there is not yet any instance? | 18:03 |
| aelkner | ignas? | 18:07 |
| ignas | i guess | 18:07 |
| ignas | for the case when you do | 18:08 |
| ignas | Section.members | 18:08 |
| ignas | not really sure about it | 18:08 |
| aelkner | ok, i'm done asking about it as I know it will work in a way that i can expect | 18:09 |
| aelkner | so i'm reading the rest of your chat from yesterday to catch up | 18:09 |
| ignas | ok | 18:15 |
| aelkner | ignas: i read your discussion with th1a, but i'm still hazy about your design ideas (regardless of security) | 18:31 |
| th1a_ | Hazy about what? | 18:32 |
| aelkner | i mean, could you perhaps give an example of the object interaction of terms and sections? | 18:32 |
| aelkner | terms are date ranges with schooldays logic, i see that | 18:32 |
| aelkner | sections have members and instructors | 18:33 |
| aelkner | how would you see them interacting? | 18:33 |
| ignas | you see - when school year ends | 18:33 |
| ignas | old timetables become pretty much useless for the next year | 18:33 |
| ignas | most schools do them form scratch every year | 18:33 |
| aelkner | makes sense | 18:34 |
| ignas | new sections, with new members | 18:34 |
| ignas | etc. | 18:34 |
| aelkner | that's what i wold expect | 18:34 |
| th1a_ | A specific section shouldn't last longer than a year ever. | 18:34 |
| aelkner | right | 18:34 |
| ignas | so while person and school years are permanent objects | 18:34 |
| ignas | sections only live as long as a yeatr | 18:35 |
| aelkner | wait | 18:35 |
| ignas | most of the time - only 1 term actually | 18:35 |
| aelkner | when you say lve, you're referring to locking out changes, right? | 18:35 |
| ignas | yes, changes like "members" for example | 18:35 |
| ignas | if you kick someone after the last day of the term - it just does not change anything | 18:36 |
| ignas | you still can delete the user from the section so it would look like he never was in the section | 18:36 |
| ignas | even if the term is over | 18:36 |
| aelkner | and we want to prevent that | 18:36 |
| ignas | but you can't delete a user in the way that is tracked by the system as a sensible change | 18:36 |
| aelkner | ? | 18:37 |
| ignas | let me try | 18:37 |
| th1a | Well, there is some question about whether a year is a term. | 18:37 |
| ignas | well - if you are not redoing timetables in the middle of the year | 18:37 |
| ignas | you probably don't need terms, and if you are redoing timetables - sections should expire | 18:37 |
| ignas | now for sections | 18:37 |
| ignas | what you can do with a section that is "connected" to a specific term | 18:38 |
| ignas | you can say that "pete" is in section since day 1 | 18:38 |
| ignas | you can say that "john" was in the section from day 1 and got kicked out of it on day 50 | 18:38 |
| ignas | what you can't say (and that is because the section is related to the term) | 18:38 |
| ignas | that "ann" was in the section since day 1 but got kicked out of it on day 500 | 18:39 |
| aelkner | could you explain how that would look in the section object def | 18:39 |
| ignas | aelkner: i don't know, i don't have the implementation at the moment, my idea is that you have 2 ways to query the data | 18:39 |
| ignas | you either ask for the snapshot with a specific school day in mind | 18:39 |
| ignas | or you ask for the snapshot for "today" | 18:39 |
| ignas | default is today | 18:40 |
| ignas | so you would see current members of the section | 18:40 |
| ignas | but if you pass it some "old" school day - you can see the section it was some time ago | 18:40 |
| ignas | with an interface to go through all the changes (needed to dsiplay a sane gradebook) | 18:40 |
| ignas | lyceum gradebook | 18:41 |
| ignas | section attendance in your case | 18:41 |
| ignas | old code will probably work most of the time, but it will be showing only the "current" state of the system | 18:41 |
| ignas | so if you delete john from the section - old parts will think that john was never in there | 18:41 |
| ignas | while new parts of the system will be capable of showing that john was there, but now is not | 18:42 |
| aelkner | you mean when someone iterates over mysection.members, they get only the current members | 18:43 |
| ignas | yes | 18:43 |
| ignas | just as they do now | 18:43 |
| aelkner | which is ok most of the time | 18:43 |
| ignas | because we don't have the tracking | 18:43 |
| ignas | yes, most of the time it's ok | 18:44 |
| aelkner | liek attendance | 18:44 |
| aelkner | but for a grading perios | 18:44 |
| aelkner | we need to see the student who is no longer there | 18:44 |
| ignas | in attendance - it's not ok, because you want the state of the section during that specific date you are doing attendance for | 18:44 |
| aelkner | but was there at the start | 18:44 |
| ignas | you will need to do that, at the moment - it works and you are not doing it | 18:45 |
| ignas | but yes - the gradebook will probably have to be modified | 18:45 |
| ignas | to take advantage of the new features | 18:45 |
| aelkner | so we need to query members by time | 18:45 |
| ignas | yes, it should be quite easy if your grading periods have time spans defined for them | 18:45 |
| *** kkubasik has joined #schooltool | 18:46 | |
| ignas | otoh - the data will be there, but it will be the job of the gradebook to either take advantage of it | 18:46 |
| ignas | or not ;) | 18:46 |
| aelkner | we should define the members attribute as boing a query | 18:47 |
| aelkner | with the date as an argument | 18:47 |
| aelkner | ans perhaps today as the defult | 18:47 |
| aelkner | if we make it a property | 18:47 |
| ignas | i don't really know what the interface will be at the moment | 18:47 |
| aelkner | that takes one argument that is optional? | 18:47 |
| aelkner | then the old code would still work? | 18:48 |
| ignas | it will take time to settle everything down, and to implement it | 18:48 |
| ignas | but yes - i will try to keep the old code working | 18:48 |
| ignas | you will maybe have to adapt the section to some interface to access it's history | 18:48 |
| aelkner | i need to see the implementation (even if it is just what if) in order to understand the problem | 18:48 |
| ignas | there is no implementation | 18:49 |
| ignas | there is a set of usecases | 18:49 |
| aelkner | i'm talking what if | 18:49 |
| ignas | and a drawing on the whiteboard | 18:49 |
| aelkner | the whiteboard? | 18:49 |
| aelkner | is that something i could look at? | 18:49 |
| ignas | yes, in my office ;) | 18:49 |
| aelkner | that helps :) | 18:49 |
| ignas | i can take a photo, no it won't help too much | 18:49 |
| aelkner | could you indulge my discussion for a moment | 18:50 |
| ignas | indulge ? | 18:50 |
| aelkner | and consider what members might look lke in an implementation | 18:50 |
| aelkner | we have code that does list(mysection.members) | 18:50 |
| ignas | i don't know, i have yet to design it | 18:50 |
| aelkner | indulge me, what if? | 18:51 |
| aelkner | what if members were a property? | 18:51 |
| aelkner | list(mysection.members) would work | 18:51 |
| aelkner | becuase the property would have a defult date | 18:51 |
| aelkner | like None meaning today | 18:52 |
| aelkner | then anyone needing historical members | 18:52 |
| aelkner | like the gradebook | 18:52 |
| aelkner | could use the grading period dates to get all members of the grading period | 18:52 |
| aelkner | @property | 18:52 |
| aelkner | def members(self, date=None): | 18:52 |
| aelkner | etc, etc. | 18:53 |
| ignas | emm, properties don't work this way | 18:53 |
| aelkner | does this look like something that could potentially make sense? | 18:53 |
| ignas | having a property that acts as a list and as a callable at the same time is possible | 18:53 |
| ignas | but it is a hack | 18:53 |
| ignas | the history access will be needed for a lot of objects | 18:53 |
| ignas | like half of all the objects in schooltool | 18:53 |
| ignas | so i am thinking of having some adapters (maybe) | 18:54 |
| aelkner | ok, forget my recent idea | 18:54 |
| aelkner | so members always will return the current members | 18:54 |
| ignas | yes | 18:54 |
| aelkner | and a new method (or adapter) would give historical access | 18:54 |
| ignas | maybe i'll make it like ISectionHistory(section, date) | 18:54 |
| ignas | which returns an ISection object | 18:55 |
| ignas | that is tied to that date | 18:55 |
| ignas | and IKeyframes(section).__iter__() | 18:55 |
| ignas | to go through all the changes | 18:55 |
| ignas | in an efficient manner | 18:56 |
| * mgedmin wonders why IKeyframes instead of IKeyFrames | 18:56 | |
| aelkner | where do you think the historical membershp could be stored? | 18:57 |
| ignas | in the section | 18:57 |
| aelkner | annotations? | 18:57 |
| ignas | i will be rewriting most of the objects | 18:57 |
| ignas | probably directly | 18:57 |
| aelkner | rewriting? | 18:57 |
| th1a_ | Perhaps it is good we didn't get a release in Gutsy. | 18:58 |
| aelkner | are you refering to changing section class and evolving? | 18:58 |
| ignas | both | 18:58 |
| th1a_ | I guess we will have to evolve for CanDo. | 18:58 |
| ignas | most of the things that need their history tracked | 18:59 |
| ignas | have the trackable information | 18:59 |
| ignas | in annotations | 18:59 |
| ignas | (relationships for example) | 18:59 |
| aelkner | i noticed | 18:59 |
| ignas | so section will get an attribute for storing of it's keyframes | 18:59 |
| ignas | a new class will appear that will define a keyframe for a section | 18:59 |
| ignas | and an initial keyframe will be created from the initial state of the section | 19:00 |
| aelkner | may i interrupt to ask for definiiton of keyframe? | 19:00 |
| aelkner | i say you and Tom discuss it, | 19:00 |
| aelkner | but i'm not familiar | 19:00 |
| ignas | well - section is an object | 19:00 |
| ignas | term is a set of discrete steps in time | 19:01 |
| ignas | so you can look at the combined thing as an animation | 19:01 |
| ignas | animations are defined using a "state" like (this sphere is in coordinates x,y) | 19:01 |
| ignas | and a set of keyframes of the format (t1, x1, y1) | 19:01 |
| ignas | so if you remove peter, you can store either the whole state in the slot, or just the delta | 19:02 |
| aelkner | so a keyfram is a state for a given time | 19:02 |
| aelkner | or a delta | 19:02 |
| ignas | yes | 19:02 |
| ignas | the point is that when you take some specific school day | 19:02 |
| ignas | you can reconstruct the state of the object in that time by taking the initial state | 19:02 |
| ignas | and combining it with all the states inbetween the t0 and the school day you are interested in | 19:03 |
| aelkner | got it | 19:03 |
| aelkner | so 10 days into the term, jonny is removed | 19:03 |
| aelkner | results in delta -jonny | 19:03 |
| ignas | yes | 19:04 |
| aelkner | so the adapter will go through the logic you referred to to return a section with the right members for that date | 19:04 |
| ignas | yes | 19:06 |
| ignas | http://ignas.pov.lt/wb.jpg | 19:06 |
| ignas | the whiteboard | 19:06 |
| aelkner | i think the word chaos is appropriate :) | 19:07 |
| aelkner | but all kidding aside, i think i'm getting an idea of where this is heading | 19:08 |
| aelkner | and it doesn't look like it will be hard to use | 19:08 |
| aelkner | what about grading periods? | 19:09 |
| aelkner | they would also be derived from DateRange, right? | 19:09 |
| ignas | yes, just that they would not matter ;) | 19:09 |
| ignas | as in - they will not be "time managers" for any of the content objects | 19:09 |
| ignas | most probably at least | 19:10 |
| ignas | it is possible to implement them outside of terms actually | 19:10 |
| aelkner | i have a worksheet which is a grid of students by activities | 19:10 |
| aelkner | currently the worksheet has not time | 19:10 |
| aelkner | but it would need to | 19:10 |
| ignas | not necessarily | 19:11 |
| aelkner | in orrder to bring up the right students | 19:11 |
| ignas | it's up to the logic you want to have | 19:11 |
| ignas | and what you want to do with students that get removed in the middle of the term | 19:11 |
| ignas | if you want them to have only grades for the first grading period - then you can add dates to worksheets | 19:11 |
| aelkner | i think it only makes sense to have all students that were in the section for at least one day appear in the worksheet | 19:12 |
| ignas | but it's still up to you to decide if a person has grades if he was present in the end of the period, or if he was present in the beginning | 19:12 |
| aelkner | so the worksheet having a date range would help | 19:12 |
| aelkner | up to the teaher you mean | 19:13 |
| ignas | or up to you | 19:13 |
| ignas | ;) | 19:13 |
| aelkner | i woudl think that the student needs to appear | 19:13 |
| aelkner | that reminds the teacher of the history | 19:13 |
| aelkner | but then again the teacher may not want to see the student | 19:14 |
| aelkner | if they left the class after only one day | 19:14 |
| aelkner | didn't do any assinments | 19:14 |
| aelkner | or as you say | 19:14 |
| aelkner | if they entered right at the end | 19:14 |
| aelkner | maybe the teacher doesn';t want to give them a grade for the worksheet | 19:14 |
| ignas | you will always be able to remove the student as if he wasn't in the section by the way | 19:15 |
| ignas | you will modify the keyframes['0'] | 19:15 |
| aelkner | another adpater that would remove the deltas? | 19:15 |
| ignas | and wham - the student is gone without any trace | 19:15 |
| ignas | not remove, just modify | 19:15 |
| aelkner | and the teacher shoudl have a UI element to remove the student | 19:15 |
| ignas | i mean - if it was a mistake | 19:16 |
| aelkner | right | 19:16 |
| ignas | and the student shouldn't have ever been in the section | 19:16 |
| ignas | like when I imported some students from the last year | 19:16 |
| ignas | because of a copy paste error in gnumeric | 19:16 |
| ignas | so when performing a tracked operation | 19:17 |
| ignas | administrator will have an option to say "since when" does it happen | 19:17 |
| ignas | like - lessons will be shorter since 2008-01-25 | 19:17 |
| ignas | or pete is not a member since beginning of the term | 19:17 |
| ignas | (which means - he never was a member) | 19:17 |
| ignas | it just makes it a bit more convenient to think about such transformations to me | 19:18 |
| ignas | when I look at the problem from this perspective | 19:18 |
| aelkner | so definitely key frames is the main paradigm | 19:18 |
| ignas | removal of a member is the same operation in both cases, but the object that get's modified is different | 19:19 |
| ignas | and the part that defines "objects" or rather "slots" for these keyframes is the "Term" | 19:19 |
| ignas | or a "school year" | 19:19 |
| ignas | or some global "time scale" | 19:19 |
| ignas | for objects that outlive everything | 19:19 |
| aelkner | i noticed that currently sections can have multiple terms associated with them | 19:20 |
| aelkner | so that won't change, right? | 19:20 |
| ignas | yes, but from my experience that does not make too much sense when scheduling | 19:20 |
| ignas | it makes creation of new timetables automatically too complicated most of the times | 19:21 |
| ignas | it is easier to redo sections from scratch even if they haven't changed | 19:21 |
| ignas | than to reuse sections while creating a new schedule if they have changed | 19:21 |
| ignas | and redefine what a term is if your sections do not change for the whole year | 19:22 |
| ignas | i mean - if you divide the year, but don't change the timetable, nor sections in between of the divisions - maybe you only need grading periods ... | 19:22 |
| ignas | with one large term | 19:23 |
| aelkner | ok - i have to close this down and get ready for today's CanDo meeting | 19:25 |
| aelkner | tomorrow i have a funeral to go to, so I might not get online until late in the day | 19:26 |
| aelkner | i'll check the logs though | 19:26 |
| ignas | ok | 19:26 |
| aelkner | bye | 19:26 |
| ignas | bye | 19:26 |
| *** aelkner has quit IRC | 19:26 | |
| *** jelkner has quit IRC | 19:51 | |
| *** ignas has quit IRC | 20:12 | |
| *** mgedmin has quit IRC | 20:53 | |
| *** Ninno has joined #schooltool | 21:07 | |
| *** didymo has joined #schooltool | 22:41 | |
| *** Ninno has quit IRC | 22:50 | |
| *** kkubasik has quit IRC | 23:07 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!
