*** mgedmin has quit IRC | 00:10 | |
*** pcardune_vm is now known as pcardune_away | 00:24 | |
*** alga_ has quit IRC | 00:37 | |
*** nitromaster has joined #schooltool | 02:20 | |
*** pcardune_away is now known as pcardune_vm | 02:39 | |
*** eldar has joined #schooltool | 02:47 | |
Lumiere | hi eldar | 02:50 |
---|---|---|
Lumiere | hi pcardune_vm, nitromaster | 02:50 |
eldar | Lumiere: hey jason | 02:50 |
nitromaster | hi | 02:51 |
Lumiere | .nick Lumiere|SailorMoon | 02:51 |
pcardune_vm | hi Lumiere | 02:51 |
pcardune_vm | ??? | 02:51 |
Lumiere | back in an hour? gonna watch some sailor moon ;) | 02:51 |
eldar | eh? the meeting is in 7 minutes | 02:53 |
Lumiere | lol I know | 02:54 |
Lumiere | I'm joking | 02:54 |
* Lumiere goes to get sharp stabby things for jelkner | 02:54 | |
*** ccarey has joined #schooltool | 02:56 | |
Lumiere | hi ccarey | 02:58 |
ccarey | good evening | 02:58 |
Lumiere | ccarey: did you get my message? | 02:59 |
ccarey | i got an email about blueprints and a message on launchpad | 02:59 |
Lumiere | the message on launchpad is the one | 03:01 |
ccarey | ok | 03:02 |
ccarey | when you click on the skilldriver link | 03:02 |
ccarey | it goes to adding and removing competencies | 03:03 |
Lumiere | ccarey: right, there are 2 ways to get to skilldrivs | 03:03 |
ccarey | are the competencies what i'm supposed to separate? | 03:03 |
Lumiere | way 1 is to go to the top bar | 03:03 |
Lumiere | and click skill drivers | 03:03 |
Lumiere | that takes you to the view where you manage, create, and delete them | 03:03 |
Lumiere | the other is to go into a section and click skill drivers | 03:04 |
Lumiere | which is where you grade them | 03:04 |
Lumiere | the place you really need to work is the manage/create/delete view | 03:04 |
Lumiere | the section view needs to have the course/section lists separated, and the course lists made un-deleteable at the *section* level | 03:05 |
Lumiere | if you click course skill drivers | 03:05 |
Lumiere | you can delete course skill drivers | 03:05 |
Lumiere | eldar: if you have a few hours this week, can you go through all the blueprints and try and check off completed stuff | 03:05 |
Lumiere | ccarey: anything else on your end? | 03:06 |
* Lumiere stabs filip | 03:06 | |
ccarey | yes, ordering them by date? | 03:06 |
ccarey | how should i go about that? | 03:06 |
Lumiere | ccarey: I don't know if you can, that was a request of wbrady | 03:06 |
Lumiere | if there is no easy way to do it, post a comment on the bug | 03:07 |
Lumiere | and don't touch it | 03:07 |
Lumiere | (I'll rewrite the bug to exclude that, and write a wishlist bit for it) | 03:07 |
ccarey | alright, because i looked into it and i couldn't find a way to retrieve the original order | 03:07 |
Lumiere | ok, also please mark it in progress | 03:07 |
Lumiere | so I can tell who's on what | 03:07 |
ccarey | i don't think i can do anything with it though... | 03:08 |
ccarey | so should i unassign myself from it? | 03:08 |
Lumiere | do the part | 03:08 |
Lumiere | where you separate the section and course lists | 03:09 |
ccarey | ok | 03:09 |
Lumiere | and mention in a comment | 03:09 |
Lumiere | that order by date is non-trivial | 03:09 |
ccarey | ok so i've made a commit separating the section and course drivers at the section level | 03:10 |
Lumiere | ok | 03:10 |
Lumiere | ccarey: I'll look it ovecr | 03:11 |
ccarey | so when you go into a section and click skill drivers, that's what i've done | 03:11 |
Lumiere | ok | 03:11 |
Lumiere | grab another item and start on it | 03:11 |
ccarey | so is the other part when i click on a skilldriver? | 03:11 |
Lumiere | the other part | 03:11 |
Lumiere | is when you go into it from the "Sections" link | 03:11 |
Lumiere | Sections -> (choose a section) -> grade skill drivers | 03:12 |
Lumiere | unfortunately, I cannot look over the commit till late this week | 03:12 |
Lumiere | also, after this meeting | 03:12 |
Lumiere | I will be somewhat seriously incognito for this week | 03:12 |
ccarey | i don't see the grade skill drivers link =\ | 03:13 |
ccarey | i'm at the (choose a section) part | 03:13 |
Lumiere | ok | 03:13 |
Lumiere | you have to have a section | 03:13 |
Lumiere | nitromaster: hi? | 03:15 |
Lumiere | eldar: hi? | 03:15 |
ccarey | i do, but the only link i see about grades is "Gradebook" | 03:15 |
Lumiere | oO | 03:15 |
Lumiere | there should be "Evaluate Student Competencys | 03:15 |
Lumiere | "Grade Skill Drivers | 03:15 |
Lumiere | etc | 03:15 |
Lumiere | and at the to | 03:15 |
Lumiere | are tabs Evaluations Skill Drivers etc | 03:16 |
ccarey | i'm at the section view and i don't have any of those... | 03:17 |
ccarey | =( | 03:18 |
Lumiere | what do you see | 03:18 |
ccarey | section view with links to students, instructors, booking resources, edit section, etc, and | 03:19 |
ccarey | under the actions bar is | 03:19 |
Lumiere | I guess I wasn't clear | 03:19 |
ccarey | edit info, forum, student messageboxes, skill drivers, pending messages, add/remove members, etc. | 03:19 |
Lumiere | the default interface for cando is the *go* interface | 03:20 |
*** fsufitch has joined #schooltool | 03:20 | |
Lumiere | do http://yourinstance/++skin++NewCanDo/ | 03:20 |
Lumiere | omg it's a fsufitch | 03:20 |
fsufitch | Lumiere: hi | 03:20 |
Lumiere | only 20 minutes late | 03:20 |
fsufitch | sorry | 03:20 |
fsufitch | was teaching the constitution | 03:20 |
fsufitch | got carried away i guess | 03:20 |
fsufitch | what's going on? | 03:20 |
Lumiere | I am working through ccarey's bug with him | 03:21 |
Lumiere | just to find that he was using the admin interface | 03:21 |
Lumiere | instead of go | 03:21 |
Lumiere | fsufitch: what have you done this week? | 03:21 |
Lumiere | if anything | 03:21 |
fsufitch | i fixed that bug... | 03:22 |
fsufitch | i emailed you about it | 03:22 |
ccarey | Lumiere: wow ok this makes a lot more sense | 03:22 |
fsufitch | but apart from that, nm else | 03:22 |
Lumiere | k | 03:22 |
ccarey | i was wondering why my cando doesn't look like cando | 03:22 |
fsufitch | heh | 03:22 |
Lumiere | ccarey: I use apache magic to make the ++ go away | 03:23 |
Lumiere | fsufitch: have you seen the email about blueprints | 03:23 |
fsufitch | ccarey: a little note though. if you don't use the schooltool default skin, you can't have admin rights | 03:23 |
fsufitch | cando does not recognize the manager account | 03:23 |
ccarey | i've noticed already | 03:23 |
fsufitch | so if you ever want to brute force some knot, use the schooltool interface | 03:23 |
ccarey | you have to login as a teacher of the section | 03:23 |
ccarey | ok | 03:23 |
ccarey | yeah it looks like my last commit didn't change anything in this interface | 03:24 |
fsufitch | ccarey: which bug is this? | 03:25 |
Lumiere | anyways, I'll let you continue | 03:25 |
ccarey | separating course skill drivers from section skill drivers | 03:25 |
ccarey | in the skill drivers view | 03:25 |
* Lumiere throws a sharp stabby object at jelkner and puts the rest away | 03:25 | |
fsufitch | Lumiere: you're in a stabby mood today, eh? | 03:27 |
fsufitch | nitromaster: ayt? | 03:32 |
nitromaster | fsufitch, yes | 03:32 |
fsufitch | did you get my email about the high-priority bug? | 03:33 |
nitromaster | no | 03:33 |
fsufitch | the "error deleting message from pending messages" | 03:34 |
fsufitch | ok then | 03:34 |
fsufitch | are you working on that? | 03:34 |
fsufitch | it's assigned to you | 03:34 |
nitromaster | okay | 03:34 |
fsufitch | i was looking for a yes/no | 03:35 |
nitromaster | oh, sorry, i started working on it, but then got a bit sidetracked | 03:36 |
nitromaster | i can resume working on | 03:36 |
fsufitch | ok | 03:36 |
fsufitch | were you working on something else atm tho? | 03:36 |
fsufitch | because i'm out of a high-priority thing to work on | 03:36 |
nitromaster | not really, i've been looking at bugs and such, but nothing really definite | 03:36 |
fsufitch | ah | 03:37 |
fsufitch | are you familiar with jquery? | 03:37 |
nitromaster | yes | 03:37 |
fsufitch | then could you take over bug 145615 | 03:39 |
fsufitch | the competency number popup not staying on screen? | 03:39 |
nitromaster | okay, will do | 03:39 |
fsufitch | and i'll take over the high priority one | 03:40 |
nitromaster | ok | 03:40 |
fsufitch | i've seen that stuff before | 03:40 |
ccarey | Lumiere: actually i see the change from my previous commit | 03:40 |
ccarey | i just had to find it | 03:40 |
fsufitch | nitromaster: on launchpad you're nitromaster101? | 03:41 |
ccarey | and i found the page that i have to fix | 03:41 |
nitromaster | yea | 03:41 |
fsufitch | ok | 03:41 |
fsufitch | Lumiere: may i run away? | 03:45 |
fsufitch | i'll take that as a yes... | 03:46 |
fsufitch | i'll bbl | 03:47 |
eldar | ah shit, i got carried away | 03:56 |
eldar | and forgot about the meeting >.< | 03:56 |
*** pcardune_ has quit IRC | 04:01 | |
*** th1a_ has joined #schooltool | 04:03 | |
*** th1a__ has joined #schooltool | 04:04 | |
*** ccarey has quit IRC | 04:09 | |
*** eldar has left #schooltool | 04:20 | |
*** pcardune_vm has quit IRC | 04:20 | |
*** pcardune has joined #schooltool | 05:10 | |
*** fsufitch has quit IRC | 05:59 | |
*** pcardune has quit IRC | 06:15 | |
*** nitromaster has quit IRC | 06:15 | |
*** th1a_ has quit IRC | 06:54 | |
*** th1a__ has quit IRC | 06:54 | |
*** pcardune has joined #schooltool | 07:54 | |
*** pcardune has quit IRC | 08:02 | |
*** pcardune has joined #schooltool | 08:08 | |
*** didymo has quit IRC | 08:16 | |
*** aadvaark has joined #schooltool | 08:28 | |
*** subir has joined #schooltool | 08:32 | |
*** pcardune has quit IRC | 09:15 | |
*** subir has quit IRC | 10:17 | |
*** alga has joined #SchoolTool | 14:22 | |
*** th1a_ has joined #schooltool | 15:06 | |
*** th1a__ has joined #schooltool | 15:07 | |
*** ignas has joined #schooltool | 15:31 | |
*** th1a__ has quit IRC | 15:56 | |
*** th1a_ has quit IRC | 15:57 | |
*** mgedmin has joined #schooltool | 16:02 | |
*** aelkner has quit IRC | 16:12 | |
ignas | th1a: ayt? | 16:24 |
th1a | I am here. | 16:24 |
th1a | What's up? | 16:24 |
ignas | oh | 17:00 |
ignas | sorry, didn't see that :/ | 17:00 |
ignas | th1a: i have talked with lyceum about the UI redesign | 17:00 |
ignas | th1a: it seems that they don't really like the idea of tab menu hybrid, and think it would be too confusing | 17:01 |
ignas | and they want to be able to create new user specific tabs | 17:01 |
ignas | which i think is doable | 17:01 |
ignas | we were discussing the journal tab | 17:02 |
ignas | and Bronius suggested that he as a teacher would like to have all of his sections as Top level tabs | 17:02 |
ignas | because he has only like 6-7 of them and all of his sections have ids 2 letter long | 17:02 |
ignas | so the idea is to allow users to "hide" default tabs if they really want | 17:03 |
ignas | and add "bookmarks" | 17:03 |
ignas | that would manifest as tabs | 17:03 |
ignas | even if links go to other websites, for easier integration with wordpress and moodle for example | 17:03 |
ignas | if you don't like the idea, i can quite easily implement it for lyceum only | 17:04 |
*** aelkner_ has joined #schooltool | 17:09 | |
ignas | th1a: so I think i'll drop the last 2 parts (the ones after the dotted line) of my plan, and do the user manageable tabs instead | 17:16 |
ignas | because I was planing to do the tab/menu thing for lyceum mostly | 17:16 |
th1a | Sorry, I was in the shower and then talking to jelkner. | 17:20 |
th1a | ignas: Hm... I think bookmark tabs are a good idea. | 17:23 |
ignas | good :) | 17:23 |
*** mattva01 has joined #schooltool | 17:23 | |
th1a | How well it will really work in practice is hard to say. | 17:23 |
th1a | But it seems easy enough. | 17:23 |
ignas | especially if we will manage to do some ajax magic | 17:24 |
ignas | if we'll have time of course | 17:24 |
th1a | I do think you could argue that since we're overall reducing the amount of administrative space we're taking up at the top of the screen, | 17:24 |
th1a | that it would be ok to just make "Journal" the default tab and the sections a second row of tabs. | 17:25 |
th1a | But I don't know what people would really prefer. | 17:25 |
th1a | But obviously the optimizations are different for cases where you're really only using one component compared to several. | 17:25 |
ignas | in lyceum case | 17:25 |
ignas | it is just a tad more convenient to have easy access to sections | 17:26 |
ignas | for quite a lot of teachers it seems | 17:26 |
th1a | Sure. | 17:28 |
ignas | though we can find a compromise, i don't want to discard the second level for sections idea completely | 17:28 |
ignas | just that - i want to be able to disable it | 17:28 |
th1a | Also, some schools may have up to 10 sections for a teacher or student and longer names, so that makes tabs problematic in the general case. | 17:29 |
th1a | A drop down is probably safer universally to select sections. | 17:29 |
ignas | a plain list of sections | 17:29 |
ignas | when you click on journal | 17:29 |
ignas | is the safest bet most of the time | 17:29 |
th1a | Yes. | 17:29 |
th1a | The bookmark tab idea is fine though. | 17:30 |
th1a | Easy customizations are good. | 17:30 |
ignas | one more thing, but i am not sure we can fit it in scope was the ability to add a custom "menu" instead of a tab | 17:31 |
ignas | but it would require more work | 17:31 |
th1a | To make your menu idea an option? | 17:31 |
ignas | custom menu as in - a folder for bookmarks | 17:31 |
ignas | not a tab | 17:31 |
ignas | for a section, but a menu that can contain sections. Though it's useful only for a bit more power users. | 17:32 |
th1a | Right. | 17:32 |
ignas | and would require me to add a bit more complex tab list menu | 17:32 |
ignas | not more complicated, but more complex | 17:32 |
ignas | so i think of leaving it for the time after the sprint | 17:33 |
th1a | ok | 17:34 |
*** pcardune has joined #schooltool | 18:48 | |
mattva01 | http://pastebin.com/m6f615eba | 19:09 |
ignas | mattva01: someone is sorting a list | 19:11 |
ignas | that contains decimals and strings | 19:11 |
ignas | in schooltool.gradebook code | 19:11 |
ignas | again | 19:12 |
ignas | or was it cando that did that the last time | 19:12 |
*** pcardune has quit IRC | 19:12 | |
*** pcardune has joined #schooltool | 19:13 | |
*** pcardune_vm_ has joined #schooltool | 19:14 | |
*** pcardune_vm_ is now known as pcardune_vm | 19:14 | |
*** lisppaste5 has quit IRC | 19:24 | |
*** mattva01 has quit IRC | 19:30 | |
*** lisppaste5 has joined #schooltool | 19:33 | |
aelkner_ | ignas: ayt? | 19:47 |
*** wbrady has joined #schooltool | 19:49 | |
ignas | aelkner_: yes | 19:49 |
aelkner_ | hey there | 19:50 |
aelkner_ | i fixed the gradebook porblem | 19:50 |
ignas | hi | 19:50 |
aelkner_ | it was not handling UNSCORED grades well | 19:50 |
aelkner_ | anyway | 19:50 |
aelkner_ | i have some questions about my csap work here i'd like to bounce off of you | 19:50 |
ignas | i see | 19:51 |
ignas | ok | 19:51 |
ignas | i have only like 20-30 minutes though | 19:51 |
aelkner_ | basically, we have four types of objects that deal with csap, ITier1Message, ITier2BASE, ITier2Goal and ITier3Record | 19:52 |
aelkner_ | I could have different containers for these | 19:52 |
aelkner_ | off of the app root | 19:52 |
aelkner_ | schooltool.csap.iter1 | 19:52 |
aelkner_ | etc. | 19:52 |
aelkner_ | and I could just put all of the messages of the given types in the right containers | 19:53 |
aelkner_ | then I would just need the containers to have get functions for finding the objects that relate to a given student | 19:53 |
ignas | hmm, i don't really know, what objects are these items related to? | 19:54 |
ignas | and are they related to each other? | 19:54 |
ignas | students? | 19:54 |
aelkner_ | i need to call then all up for a given student | 19:54 |
aelkner_ | them | 19:54 |
aelkner_ | so each one of these objects will have the student as an attribute | 19:54 |
th1a | They represent different levels of intervention. | 19:54 |
aelkner_ | yes | 19:54 |
ignas | is the relationship between student and each item 1:1 ? | 19:54 |
ignas | or can student have multiple items of one time assigned to him? | 19:55 |
aelkner_ | there can be any number of messages or tier2 goals for a given student | 19:55 |
ignas | can he have Tier1Message and Tier2goal without having tier2base for example? | 19:55 |
aelkner_ | no, there has to be a tier2base for there to be a goal | 19:55 |
ignas | as in - are these 4 objects related somehow among themselves? | 19:55 |
aelkner_ | but tier1messages con't need tier2 | 19:56 |
ignas | and how are they related | 19:56 |
aelkner_ | they all have the student as an attrubute | 19:56 |
ignas | i understand, but what about themselves... is there something like - you must have tier1message to have tier2base | 19:56 |
ignas | and you must have tier2base to have a tier2goal | 19:57 |
aelkner_ | no | 19:57 |
aelkner_ | wait | 19:57 |
aelkner_ | yes, you must have tier2base to have tier2goal | 19:57 |
ignas | so it's 3 independent groups of objects | 19:57 |
ignas | and tier2 objects are related to each other how? 1:1 1:many ? | 19:57 |
aelkner_ | 1 tier2base to many tier2goal objects | 19:58 |
ignas | can you have tier2stuff without tier1stuff and tier3 stuff without tier2 nor tier1 stuff? | 19:58 |
aelkner_ | could be | 19:59 |
aelkner_ | not likely in practice | 19:59 |
aelkner_ | but i have to allow for it | 19:59 |
ignas | i see | 19:59 |
ignas | so it seems that you need 3 containers keyed by person __name__ one for tier1 another for tier2base objects that have a list of tier2goals as their attribute and one for tier3 objects | 20:00 |
ignas | whether you put them in a top level object like app['sla.casp'].tier1 app['sla.casp'].tier2 and app['sla.casp'].tier3 | 20:01 |
ignas | or as 3 top level containers | 20:01 |
ignas | does not matter that much | 20:01 |
ignas | i think you know possible directions and ways in which you might want to extend the system | 20:01 |
ignas | so it's really up to you to decide | 20:01 |
ignas | and - is it schooltool.csap ? | 20:02 |
ignas | i mean - is that module in schooltool namespace? | 20:02 |
aelkner_ | tom wants it to be schooltool.csap | 20:02 |
aelkner_ | even though i'm doing it for sla | 20:02 |
ignas | hmm, i'd not go there at the moment | 20:02 |
aelkner_ | he wants this to be available for others | 20:02 |
ignas | it will need to be refactored into a separate egg | 20:02 |
ignas | before doing that | 20:03 |
ignas | so i'd go with sla.something | 20:03 |
aelkner_ | why? | 20:03 |
aelkner_ | it's just a name | 20:03 |
ignas | so you could install it | 20:03 |
ignas | i just think that you should not use names of packages that do not exist | 20:03 |
ignas | and use namespaces based on your current namespaces rather than introducing new ones | 20:04 |
aelkner_ | could we leave packaging issues for later? | 20:04 |
th1a | I have no opinion about the top level namespace. | 20:04 |
aelkner_ | i wanted to tell you my idea for this | 20:04 |
aelkner_ | that's slightly different from yours | 20:04 |
aelkner_ | here's what would be easiest for me | 20:05 |
aelkner_ | i create a container called app['sla.csap'] | 20:05 |
aelkner_ | in it are entries keyed by student_id | 20:05 |
aelkner_ | each entry would be the top-level csap container for the given student | 20:06 |
aelkner_ | in it would be a hetrogenous mix of Tier1, Tier2 and Tier3 objects | 20:06 |
aelkner_ | so | 20:06 |
ignas | well - it works too, it might be more comfortable as you have a csap container that you can register views for, though i would not put tier 2 objects in the same hierarchy level as their relationship is quite rigid | 20:07 |
aelkner_ | the tier2 object can itself be a container | 20:07 |
ignas | yes | 20:07 |
ignas | that's my point | 20:07 |
aelkner_ | it's attibutes would describe the base | 20:07 |
aelkner_ | but its contents would be the goal objects | 20:08 |
ignas | makes sense | 20:08 |
aelkner_ | this is good news | 20:08 |
aelkner_ | tom didn;'t think you';d agree with this | 20:08 |
aelkner_ | but that's why i asked you | 20:08 |
aelkner_ | just in case | 20:08 |
ignas | i mean - it's your code, you should decide, it's you who will have to live with it ;) | 20:09 |
aelkner_ | tom seemed to think that we like to keep everything at a top-level | 20:09 |
ignas | if i make the decision and it makes it inconvenient to you - i won learn | 20:09 |
aelkner_ | find of a flat heirarchy | 20:09 |
ignas | i won't learn the lesson ;) | 20:09 |
aelkner_ | hehe | 20:09 |
ignas | as it's you who will face the consequences | 20:09 |
aelkner_ | but that's why i ask | 20:09 |
aelkner_ | what kind of consequences would you anticipate with my idea | 20:10 |
aelkner_ | see i love it for two reasons | 20:10 |
aelkner_ | everything is easy to find by student id | 20:10 |
ignas | hmm, listing only 1 type of objects becomes a task that requires iterating + filtering of all the objects in the container | 20:10 |
aelkner_ | i'll never need to create a catalog to speed up performance | 20:10 |
ignas | so you can't say - give me tier 1 objects | 20:10 |
ignas | and it does not make much sense unless all tier objects implement the same interface | 20:11 |
ignas | having 3 containers indexed by student id is just as fast | 20:11 |
aelkner_ | my container can have get method for each type of object | 20:11 |
th1a | I guess one thing is that it isn't like you have to always have the list of csap containers exactly in sync with the list of students. | 20:11 |
aelkner_ | how do you mean? | 20:12 |
ignas | aelkner_: they can have that, but it requires extending the container if you want to add another type of objects | 20:12 |
ignas | aelkner_: which is not that easy if you are developing an extension | 20:12 |
th1a | I mean, you don't have to make a csap folder as soon as a student is created and destroy it if they are deleted (which generally shouldn't happen anyhow). | 20:12 |
ignas | th1a: he can do the same with his system, anyway | 20:13 |
aelkner_ | i only need to create the csap folder when the UI discates it | 20:13 |
aelkner_ | i.e., when a student gets in trouble | 20:13 |
ignas | th1a: "write on read" and a subscriber for IObjectRemoved | 20:13 |
ignas | th1a: what aelkner_ said | 20:13 |
ignas | but that works with 3 separate containers for different tier objects | 20:14 |
th1a | I guess I'm just saying that as a general pattern, it would get hairy if every time a student was created, that 12 folders scattered around the system were created for them. | 20:14 |
aelkner_ | right | 20:14 |
ignas | th1a: it is not going to be so | 20:14 |
aelkner_ | that's why i want just the one folder | 20:14 |
ignas | th1a: most of the containers get created only when you try to access them | 20:14 |
aelkner_ | and if a student is removed | 20:14 |
aelkner_ | i can remove the folder | 20:14 |
ignas | and it is not that hairy | 20:14 |
th1a | So... I'm not arguing against this. | 20:14 |
th1a | I'm just kind of meekly justifying my initial concern ;-) | 20:15 |
ignas | as for the tier containers | 20:15 |
ignas | you can have 3 of them in top level you can have 3 of them in the common container indexed by student id | 20:15 |
ignas | it works both ways | 20:15 |
ignas | what i don't like is having 3 types of objects in one container | 20:15 |
ignas | unless they have a common interface | 20:15 |
ignas | that is actually being used | 20:15 |
ignas | i mean groups and persons have common IContentObject interface, but we are not putting them in the same container | 20:16 |
ignas | even though we could filter them out | 20:16 |
th1a | I just noticed flickr uses the same kind of "temporary tabs" I proposed two years ago for SchoolTool... | 20:16 |
aelkner_ | thing is, groups and persons clearly exist independently of one-another | 20:17 |
ignas | th1a: i'll have to go see them, as I have never understood the proposal fully | 20:17 |
aelkner_ | in my case, all data related to a student kind of goes together in the UI | 20:17 |
ignas | yes and it can go | 20:17 |
ignas | my point is | 20:17 |
ignas | it should be app['sla.csap']['peter']['tier1'] | 20:18 |
ignas | app['sla.csap']['peter']['tier2'] | 20:18 |
ignas | app['sla.csap']['peter']['tier3'] | 20:18 |
th1a | OK, is this legible: http://www.flickr.com/photos/14049009@N00/sets/72157604046708333/ | 20:18 |
ignas | because in the context of a single student | 20:18 |
ignas | just like in the context of a single application | 20:18 |
ignas | different tiers are well - different | 20:18 |
aelkner_ | ignas: what would tier1, tier2, etc. be? | 20:18 |
aelkner_ | plain BTreeContainers? | 20:19 |
ignas | containers | 20:19 |
ignas | probably, if it's good enough | 20:19 |
aelkner_ | well, for tier2, i have the base and the goals | 20:19 |
aelkner_ | where would the base attributes go? | 20:19 |
aelkner_ | in app['sla.csap']['peter']['tier2']? | 20:20 |
ignas | ['tier2'] can be a PersistentList of bases | 20:20 |
ignas | it seemed to me that you were planning to have app['sla.csap']['peter'] a PersistentList or a BTree | 20:20 |
ignas | so instead of having 1 list or a btree | 20:20 |
ignas | you separate different objects into 3 lists or btrees | 20:20 |
ignas | so you get an index for each type of tier | 20:21 |
aelkner_ | btrees make traversal easier | 20:21 |
ignas | instead of filtering every time | 20:21 |
ignas | indeed, PersistentList does not make much sense | 20:21 |
ignas | as for traversal you will probably have ICASPInfo(person) adapter | 20:21 |
*** wbrady has quit IRC | 20:22 | |
ignas | and access the info in some specific way on the person anyway | 20:22 |
aelkner_ | i mean when createing a link | 20:22 |
ignas | not traversing into the top level container directly | 20:22 |
ignas | so you add an adapter traversal for "casp" on person that adapts person to ICASPInfo() | 20:22 |
aelkner_ | for instance: /localhost/interventions/aelkner/tier1/1 | 20:23 |
ignas | and register different views on the ICASPInfo() | 20:23 |
ignas | nope localhost/aelkner/interventions/tier1/1 | 20:23 |
ignas | at least that's what i'd suggest | 20:23 |
aelkner_ | you have it backwards | 20:23 |
ignas | the actual location of interventions is an implementation detail | 20:23 |
aelkner_ | /localhost/persons/aelkner is a person | 20:23 |
ignas | if they are always related to a person | 20:24 |
aelkner_ | so: /localhost/interventions/aelkner/tier1/1 | 20:24 |
ignas | yes /localhost/person/aelkner/interventions are his interventions | 20:24 |
aelkner_ | no | 20:24 |
ignas | yes | 20:24 |
aelkner_ | that implies IBasicPerson is a container | 20:24 |
ignas | no | 20:24 |
aelkner_ | i wasn't suggesting that | 20:24 |
ignas | it implies that there is a traversal plugin | 20:25 |
aelkner_ | i wasn't thinkinbg traversal adapters | 20:25 |
ignas | that when traversing into ';interventions' on a person | 20:25 |
aelkner_ | i was figuring that using btrees | 20:25 |
ignas | returns the right object | 20:25 |
ignas | no matter where it is | 20:25 |
aelkner_ | gives me the traversal for free | 20:25 |
ignas | well - it's up to you I guess, i just liked the simple indirection step | 20:25 |
ignas | that gives you freedom to move containers around | 20:25 |
ignas | because the actual place | 20:25 |
ignas | like 'sla.foo' or 'schooltool.foo' | 20:26 |
ignas | is an implementation detail | 20:26 |
ignas | that can be hidden in the adapter | 20:26 |
ignas | with like 4-5 lines of code | 20:26 |
aelkner_ | what would it take to move 'persons' around? | 20:26 |
aelkner_ | my point being, why allow for it? | 20:26 |
ignas | not 'persons' | 20:26 |
aelkner_ | i'm saying for instance | 20:26 |
aelkner_ | persons is a container of of the root | 20:27 |
ignas | well - lyceum.person and schooltool.basicperson | 20:27 |
aelkner_ | would we be able to change the name easily? | 20:27 |
ignas | and migration to sql database for persons | 20:27 |
ignas | are 3 usecases | 20:27 |
ignas | not at the moment, because we are not using this pattern for persons and groups | 20:27 |
ignas | because well - they are old | 20:27 |
aelkner_ | so you're saying that if you had it to do over again... | 20:27 |
ignas | for example localhost/person/aelkner/gradebook is lyceum.journal gradebook and localhost/sections/math/journal | 20:27 |
ignas | are links to objects that are in app['schooltool.lyceum.journal'] | 20:28 |
ignas | aelkner_: yes, i would allow for easy switching to sql database for persons for example | 20:28 |
ignas | aelkner_: or LDAP | 20:28 |
ignas | aelkner_: or for migration of person container to another type of persons | 20:28 |
ignas | aelkner_: while application is running | 20:28 |
ignas | by accessing person container using | 20:28 |
ignas | IPersonsGateway(app) | 20:28 |
ignas | isntead of app['persons'] | 20:29 |
ignas | or even IPersons(app) | 20:29 |
ignas | which is the same ammount of letters (actually 1 letter shorter) | 20:29 |
ignas | but gives use the ability to change the implementation of person container | 20:29 |
aelkner_ | we may need to do that kind of thing with persons | 20:29 |
aelkner_ | because one authenticates with them | 20:30 |
ignas | same for all the top level containers | 20:30 |
aelkner_ | but what about sections | 20:30 |
ignas | and even sections, i mean - who decided that sections will always be in the ZODB | 20:30 |
ignas | we did | 20:30 |
ignas | did we do it intentionally? | 20:30 |
ignas | no, it was just the way we did it | 20:31 |
ignas | to me the navigation to csap seems more natural if you do it through persons (on the url) | 20:31 |
ignas | because it belongs to the person | 20:31 |
ignas | data structures do not have to match the way user sees the person | 20:31 |
ignas | but it's just my opinion | 20:31 |
ignas | and i would suggest using a way of traversing to CSAP that is not relying on some internal structure | 20:32 |
ignas | thus not exposing arbitrary implementation details | 20:32 |
ignas | to the user | 20:32 |
ignas | like calendars | 20:32 |
ignas | they live in person/calendar | 20:32 |
ignas | not perons/__annotations__/schooltool.calendar | 20:33 |
ignas | because the fact that calendar is in annotations is an implementation detail | 20:33 |
ignas | look at these top level containers as indirect annotations | 20:33 |
aelkner_ | so you have a traversal adapter for person -> calendar, right? | 20:33 |
ignas | yes | 20:33 |
ignas | because they are a fancy kind of annotations that does not "pollute" the person object | 20:33 |
aelkner_ | ok, so you suggest that it's ok to create the csap container by person in spp'interventions'] | 20:34 |
ignas | so isntead of IAnnotations(person)['schooltool.calendar'] you'd do app['schooltool.calendar'][person.__name__] | 20:34 |
ignas | yes | 20:34 |
aelkner_ | but that i should traverse to the stuff using adapters | 20:34 |
ignas | jsut that instead of the csap container having 3 types of items | 20:35 |
aelkner_ | to hide the impementation | 20:35 |
ignas | i am suggesting 3 containers in ther | 20:35 |
ignas | yes | 20:35 |
ignas | so if you will suddenly realize that my suggestion is better (not necessary) | 20:35 |
aelkner_ | so even though i would hide implementation with traversal adapters | 20:35 |
ignas | you can just change the adapter | 20:35 |
ignas | adapters can return LocationProxy objects that have the person as their __parent__ | 20:35 |
ignas | so that urls would look the way you want | 20:36 |
aelkner_ | it's still true that /localhost/interventions/aelkner/tier1/1 would traverse to the first tier1 message for aelkner | 20:36 |
aelkner_ | i just wouldn't use that in my pages | 20:36 |
aelkner_ | zpts | 20:36 |
ignas | no, not necessary | 20:36 |
ignas | if you will register | 20:36 |
ignas | a traversal adapter | 20:36 |
ignas | for application to traverse to sla.csap | 20:36 |
ignas | when traversing to 'interventions' then yes | 20:37 |
ignas | but it won't happen automatically | 20:37 |
aelkner_ | i'm just saying that i don't NEED the traversal adapters to get the job done | 20:38 |
aelkner_ | i just want to use them to hide the btree stuff | 20:38 |
ignas | yes you don't NEED them strictly speaking | 20:39 |
ignas | but i am suggesting you to add a thin level of indirection to make urls a bit more sane and keep the tradition of app/container/object/stuff_related_to_object | 20:39 |
ignas | instead of app/calendars/john/2007-01-01 | 20:40 |
ignas | or app/journal/1/ | 20:40 |
*** alga has quit IRC | 20:41 | |
aelkner_ | ok, so i should feel free to develop everything without the traversal adapters and add them shortly before delivering to the user | 20:42 |
aelkner_ | sound ok? | 20:42 |
ignas | yes | 20:42 |
aelkner_ | thanks for the input | 20:42 |
ignas | i only care about the end result | 20:42 |
ignas | ;) | 20:42 |
ignas | i don't really care about csap actually ;) i don't even know what it is | 20:43 |
aelkner_ | i knbew you didn't care about the modlue itself | 20:43 |
aelkner_ | i just wanted to make sure i coded to accepted practices | 20:44 |
aelkner_ | accepted by you, that is :) | 20:44 |
th1a | The important part is that we all love and care for each other. | 20:44 |
ignas | :) | 20:44 |
th1a | So... is this legible? http://www.flickr.com/photos/14049009@N00/sets/72157604046708333/ | 20:44 |
aelkner_ | th1a: ignas suggests that i use sla.csap for the container name | 20:45 |
ignas | th1a: why not just use screenshots as the base instead? ;) | 20:45 |
aelkner_ | but you said you wanted things to be called schooltool.csap | 20:45 |
ignas | screenshots of the new navigation branch | 20:45 |
aelkner_ | which way is right? | 20:45 |
th1a | I was not really thinking about what the root module would be. | 20:46 |
ignas | the module is named sla.csap, it should use schooltool.csap *only* when/if it will be moved refactored into schooltool.csap | 20:46 |
aelkner_ | ok, i'll call all my containers sla.whatever for now | 20:47 |
ignas | you will need an evolution script if you will move the modules to schooltool.csap anyway, so changing the name of the container if you will change the name of the module will be the easy part | 20:48 |
aelkner_ | that's fine | 20:49 |
aelkner_ | th1a: you could maybe bring up the brightness and/or contrast on the photos | 20:51 |
ignas | th1a: http://licejus.pov.lt/new/ | 20:51 |
ignas | th1a: you can even use firefox view-pagestyle->some style | 20:52 |
ignas | to switch between 3 color sets ;) | 20:52 |
ignas | just print it and cut it to pieces ;) | 20:53 |
ignas | th1a: should i leave it up or just turn it off? | 20:55 |
th1a | You can turn it off. | 20:55 |
ignas | ok | 20:55 |
* ignas is going home | 20:56 | |
ignas | bye | 20:56 |
*** ignas has quit IRC | 20:56 | |
th1a | Thanks ignas. | 20:56 |
*** th1a__ has joined #schooltool | 21:30 | |
*** th1a_ has joined #schooltool | 21:30 | |
*** mgedmin has quit IRC | 21:36 | |
th1a | th1a_: http://www.careercenter.arlington.k12.va.us/cando/schooltool_ui/skills.htm | 21:43 |
Lumiere | oO | 21:49 |
*** pcardune_ has joined #schooltool | 21:49 | |
*** th1a_ has quit IRC | 21:52 | |
*** pcardune_ has quit IRC | 21:59 | |
*** pcardune_vm has quit IRC | 22:05 | |
*** pcardune has quit IRC | 22:06 | |
*** pcardune has joined #schooltool | 22:50 | |
*** pcardune has quit IRC | 22:53 | |
*** pcardune_vm has joined #schooltool | 22:53 | |
*** pcardune has joined #schooltool | 22:53 | |
*** Ninno has joined #schooltool | 22:59 | |
*** Ninno has quit IRC | 23:14 | |
*** Ninno has joined #schooltool | 23:15 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!