| *** dlobo has quit IRC | 02:58 | |
| *** replaceafill has quit IRC | 02:59 | |
| *** lisppaste5 has quit IRC | 03:11 | |
| *** lisppaste5 has joined #schooltool | 03:19 | |
| *** ignas has quit IRC | 04:03 | |
| *** dlobo has joined #schooltool | 04:04 | |
| *** dlobo has quit IRC | 04:05 | |
| *** dlobo has joined #schooltool | 04:52 | |
| *** replaceafill has joined #schooltool | 07:08 | |
| replaceafill | aelkner, ping | 08:03 |
|---|---|---|
| *** mgedmin has joined #schooltool | 09:00 | |
| *** pcardune has quit IRC | 09:18 | |
| *** alga has joined #schooltool | 09:26 | |
| *** replaceafill has quit IRC | 10:10 | |
| *** pcardune has joined #schooltool | 10:25 | |
| *** mgedmin has quit IRC | 10:32 | |
| *** mgedmin has joined #schooltool | 11:06 | |
| *** yvl has joined #schooltool | 11:17 | |
| *** pcardune has quit IRC | 13:01 | |
| *** Aiste has joined #schooltool | 13:06 | |
| *** Aiste has quit IRC | 14:08 | |
| *** yvl has quit IRC | 14:27 | |
| *** ignas has joined #schooltool | 14:53 | |
| *** ignas has quit IRC | 14:53 | |
| *** ignas has joined #schooltool | 14:54 | |
| *** ignas has quit IRC | 15:06 | |
| *** ignas has joined #schooltool | 15:08 | |
| *** Aiste has joined #schooltool | 15:24 | |
| *** th1a has joined #schooltool | 15:34 | |
| *** replaceafill has joined #schooltool | 16:16 | |
| th1a | How's it going, replaceafill? | 16:17 |
| replaceafill | hey th1a, i've implemented the checkbox to deactivate the email service | 16:18 |
| th1a | Ah. Good. | 16:18 |
| replaceafill | found a remaining bug in the gradebook | 16:18 |
| replaceafill | and it seems like i have to merge fsufitchi work into a branch from yvl | 16:19 |
| replaceafill | i've been thinking about the states too | 16:19 |
| replaceafill | question about that btw: | 16:19 |
| replaceafill | should the states be independent from school years? | 16:20 |
| th1a | Yes. | 16:20 |
| th1a | Ah... I wrote this up somewhere... | 16:21 |
| replaceafill | oh, maybe it's in the blueprint | 16:21 |
| replaceafill | "The enrollment state of a person is not set by year." | 16:23 |
| replaceafill | "It represents the *current* status of the student." | 16:23 |
| th1a | Yes. | 16:24 |
| replaceafill | th1a, i've been thinking about using relationships for this | 16:24 |
| replaceafill | like courses <-> sections <-> enrollment | 16:25 |
| replaceafill | global status <-> substatus <-> student | 16:25 |
| replaceafill | or something like that | 16:25 |
| *** alga has quit IRC | 16:58 | |
| th1a | replaceafill, back from the shower... | 17:00 |
| replaceafill | :) | 17:00 |
| th1a | That should be fine. | 17:00 |
| aelkner | replaceafill: how do you envision the relationship model? | 17:02 |
| replaceafill | aelkner, kind of like the relationship with courses and sections | 17:02 |
| aelkner | those are lists | 17:03 |
| aelkner | is yours also? | 17:03 |
| replaceafill | lists as in python lists? | 17:03 |
| aelkner | as in more than one | 17:03 |
| replaceafill | ah | 17:03 |
| aelkner | what is a status object? | 17:03 |
| replaceafill | yes, but for courses for example we use to use only one, right? | 17:04 |
| aelkner | i only remember it being a list | 17:04 |
| aelkner | but that doesn't mean a relationship has to be to a list | 17:04 |
| aelkner | i'm just wondering what the possible structure of the relationship would be | 17:05 |
| replaceafill | courses = RelationshipProperty(relationships.URICourseSections, | 17:05 |
| replaceafill | relationships.URISectionOfCourse, | 17:05 |
| replaceafill | relationships.URICourse) | 17:05 |
| replaceafill | aelkner, i was thinking of the same way competencies are associated with courses and sections in cando | 17:05 |
| replaceafill | they use relationshipproperties too | 17:06 |
| aelkner | but once again, they are multiple | 17:06 |
| aelkner | i'm just wondering if there is an example of a relationship to a singleton | 17:06 |
| replaceafill | no that i know, but again, ST is using only one course for sections | 17:07 |
| replaceafill | when it's a list | 17:07 |
| replaceafill | i think it's a UI thing not to allow them to be many | 17:07 |
| replaceafill | right? | 17:07 |
| aelkner | ST allows mulit-course sections | 17:08 |
| aelkner | isn't that the reason you changed the gradebook to use a join? | 17:08 |
| aelkner | for course title | 17:08 |
| replaceafill | no, the reason of the change is when you DONT HAVE courses | 17:08 |
| replaceafill | associated with the section | 17:09 |
| aelkner | oh | 17:09 |
| replaceafill | and you use list()[0] | 17:09 |
| replaceafill | i havent seen a title being "course1, course2" in st | 17:09 |
| replaceafill | ever | 17:09 |
| replaceafill | because the UI doesn't allow it i guess | 17:09 |
| aelkner | for some reason i thought we allowed it | 17:09 |
| replaceafill | i remember ignas explaining that *in theory* you could have a section related with many courses | 17:10 |
| replaceafill | what i like about relationships is the membership handling | 17:11 |
| ignas | yeah, multi course sections were kind of planned some time ago, you should ask th1a once more what he thinks about it ;) | 17:11 |
| aelkner | :) | 17:11 |
| replaceafill | :) | 17:11 |
| replaceafill | aelkner, you had some thoughts about the enrollment status? | 17:13 |
| aelkner | no, i was just curious about it | 17:14 |
| aelkner | i was wondering if you could have more than one status | 17:14 |
| replaceafill | ah | 17:14 |
| aelkner | and what the technical advantage was in using a relationship | 17:15 |
| replaceafill | it shouldn't be neccessary i guess according to the blueprint | 17:15 |
| replaceafill | for me it is relationship handling membership | 17:15 |
| replaceafill | but i'd have to test things out | 17:15 |
| replaceafill | to find out | 17:15 |
| aelkner | if it were just one possible status, i would just add an attribute to IBasicPerson | 17:16 |
| aelkner | no evolve script necessary | 17:16 |
| aelkner | just a class attribute like status = None | 17:16 |
| replaceafill | aelkner, but the user can set custom sub-status | 17:16 |
| aelkner | is that contained in the status? | 17:17 |
| replaceafill | i was thinking of: basic status and extended status | 17:17 |
| aelkner | or is it in addation | 17:17 |
| aelkner | addition | 17:17 |
| replaceafill | i was thinking of two attributes | 17:17 |
| replaceafill | basic_status and extended_status maybe | 17:17 |
| replaceafill | the first one, its values are not supposed to change i guess | 17:18 |
| replaceafill | and the second one, the user can define new values | 17:18 |
| aelkner | those could also be basic person attrib utes | 17:18 |
| aelkner | i'm just wondering if we want to create a relationship every tme we add an attribute to an aobject | 17:18 |
| aelkner | i mean, just to avaoid over-engineering | 17:18 |
| replaceafill | again, i like the membership handling of relationships | 17:18 |
| * th1a wakes up again. | 17:19 | |
| aelkner | it handles membership well | 17:19 |
| replaceafill | but it's just an idea anyway :) | 17:19 |
| *** Aiste has quit IRC | 17:19 | |
| replaceafill | yes | 17:19 |
| aelkner | but is it necessary for this case? | 17:19 |
| th1a | Relationships are more robust. | 17:20 |
| aelkner | the whole point of the word membership suggests an open ended group of objects of a certain type | 17:20 |
| th1a | Each person *must* have one and only one basic status. | 17:20 |
| replaceafill | i even envision the same membership form you use for enrollment :) | 17:20 |
| aelkner | a section can have any number of students | 17:20 |
| replaceafill | when you are assigning multiple people to some status | 17:21 |
| aelkner | a student any number of advisors | 17:21 |
| aelkner | etc. | 17:21 |
| th1a | Each person *may* have one extended status. | 17:21 |
| replaceafill | a section any number of courses (but we dont allow it) | 17:21 |
| aelkner | still, a singleton | 17:21 |
| th1a | I guess in theory it could be multiple. | 17:21 |
| th1a | But if we want to add logic later we'd better keep it to one. | 17:21 |
| aelkner | well, if it could be multiple | 17:22 |
| aelkner | then how about having both status and substatus as members of the same relationship | 17:22 |
| replaceafill | aelkner, the other option is a single attribute with a constraint to a vocabulary or something | 17:22 |
| th1a | Isn't one of the main reasons to use relationships that it is easier to do clean up if the global status object is deleted? | 17:22 |
| aelkner | then, when you ask for the status' you get the list | 17:22 |
| replaceafill | kind of like categories in the gradebook | 17:23 |
| aelkner | th1a: yes | 17:23 |
| replaceafill | th1a, yes | 17:23 |
| th1a | I think it is mostly a matter of style. | 17:23 |
| aelkner | that's also what i was asking about before | 17:23 |
| replaceafill | that's what i value in cando | 17:23 |
| replaceafill | you get rid of the competencies and the courses get cleaned automatically | 17:23 |
| aelkner | i agree | 17:23 |
| th1a | Fewer bugs down the road. | 17:23 |
| aelkner | once again, i'd suggest just having the one relationship | 17:24 |
| aelkner | and put the status, sub-status, and any future status ideas there | 17:25 |
| aelkner | rather than creating one relationship for EACH status type | 17:25 |
| aelkner | that would seem like overkill | 17:25 |
| aelkner | whereas if you have an open-ended number of status' | 17:25 |
| aelkner | you will always code with the assumption that the list could contain any combination | 17:26 |
| aelkner | right now, that simply being: | 17:26 |
| aelkner | 1) nothing | 17:26 |
| aelkner | 2) status alone | 17:26 |
| aelkner | 3) status and sub-status | 17:26 |
| aelkner | but that could change in the future | 17:26 |
| aelkner | and using the one relationship would stay viable | 17:27 |
| th1a | Huh? | 17:27 |
| th1a | Is anyone arguing the opposite? | 17:27 |
| aelkner | i thought replaceafill was suggesting having two relationships | 17:27 |
| th1a | Oh, I see. | 17:27 |
| th1a | Yes, replaceafill is right. | 17:28 |
| aelkner | about what? | 17:28 |
| th1a | aelkner's strategy is more complicated. | 17:28 |
| th1a | One basic relationship. | 17:29 |
| th1a | One extended relationship. | 17:29 |
| th1a | That's all you need. | 17:29 |
| replaceafill | i have thought of two global containers app['schooltool.basic_status'] and app['schooltool.extended_status'] | 17:29 |
| replaceafill | both with status objects inside | 17:29 |
| replaceafill | or whatever you want to call them | 17:29 |
| replaceafill | the basic_status container should have only three objects | 17:30 |
| aelkner | what does a status object look like? | 17:30 |
| replaceafill | pre, during, post | 17:30 |
| replaceafill | the user can modify the contents of the second container | 17:30 |
| replaceafill | two attributes (maybe in ibasicperson) would point to both containers | 17:30 |
| th1a | It is ok to bake this into basic person | 17:31 |
| replaceafill | the part that i still dont get is the history | 17:31 |
| replaceafill | th1a, you want something like: (datetime, status_changed) | 17:31 |
| th1a | Yes. | 17:32 |
| replaceafill | or (datetime, from_this_status, to_this_status) | 17:32 |
| th1a | Oh, probably the second is safer. | 17:32 |
| replaceafill | we use something like the second in competencies in cando | 17:32 |
| th1a | Also, you should probably store the statuses as strings rather than object references. | 17:32 |
| replaceafill | yes | 17:32 |
| replaceafill | for me the status objects are not that complicated | 17:33 |
| replaceafill | just a title attribute maybe | 17:33 |
| replaceafill | and an id | 17:33 |
| replaceafill | maybe | 17:33 |
| *** dlobo has quit IRC | 17:33 | |
| replaceafill | status_id and status_description | 17:33 |
| * replaceafill not sure about the names yet :/ | 17:33 | |
| *** alga has joined #schooltool | 18:25 | |
| *** dlobo has joined #schooltool | 18:54 | |
| *** dlobo has quit IRC | 19:21 | |
| *** dlobo has joined #schooltool | 19:22 | |
| *** mgedmin has quit IRC | 19:38 | |
| *** mgedmin has joined #schooltool | 20:20 | |
| *** ignas has quit IRC | 20:29 | |
| dlobo | hey th1a a quick q, does schooltool use ZODB or does it use mysql as the database? | 20:32 |
| replaceafill | dlobo, zodb :) | 20:33 |
| dlobo | replaceafill: thanx | 20:33 |
| dlobo | getting a few more requests on drupal + civicrm + SIS, so i suspect i'll take a look at schooltool and figure out integration this summer | 20:34 |
| replaceafill | dlobo, theres a schooltool.xmlrpc branch if you're interested | 20:34 |
| dlobo | cool. i'll be back on the channel actively when i start looking. tackling a few non-SIS issues at the school this year :) | 20:35 |
| *** krushik has quit IRC | 21:01 | |
| *** krushik has joined #schooltool | 21:10 | |
| *** dlobo has quit IRC | 21:45 | |
| *** dlobo has joined #schooltool | 21:46 | |
| *** dlobo has quit IRC | 21:47 | |
| *** pcardune has joined #schooltool | 21:48 | |
| *** pcardune has quit IRC | 21:56 | |
| *** mgedmin has quit IRC | 22:08 | |
| *** pcardune has joined #schooltool | 23:29 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!