| *** th1a has quit IRC | 00:59 | |
| *** alga has quit IRC | 02:13 | |
| *** menesis has quit IRC | 02:19 | |
| *** aks has joined #schooltool | 06:18 | |
| *** aks has joined #schooltool | 06:18 | |
| *** aks has quit IRC | 07:09 | |
| *** aks has joined #schooltool | 07:11 | |
| *** aks has joined #schooltool | 07:11 | |
| *** menesis has joined #schooltool | 08:14 | |
| *** yvl has joined #schooltool | 09:09 | |
| *** aks has quit IRC | 09:49 | |
| *** aks has joined #schooltool | 10:28 | |
| *** aks has joined #schooltool | 10:28 | |
| *** menesis has quit IRC | 11:20 | |
| *** menesis1 has joined #schooltool | 11:20 | |
| *** menesis1 is now known as menesis | 11:20 | |
| *** alga has joined #schooltool | 11:32 | |
| *** menesis has quit IRC | 11:33 | |
| *** menesis has joined #schooltool | 11:36 | |
| *** menesis has quit IRC | 12:00 | |
| *** menesis has joined #schooltool | 12:01 | |
| *** ignas has joined #schooltool | 14:06 | |
| *** aks has quit IRC | 14:21 | |
| *** th1a has joined #schooltool | 16:03 | |
| *** replaceafill has joined #schooltool | 16:07 | |
| th1a | hi replaceafill, aelkner_, yvl, menesis. | 16:32 |
|---|---|---|
| yvl | good morning guys | 16:33 |
| replaceafill | good morning/afternoon | 16:33 |
| menesis | hi | 16:33 |
| aelkner_ | morning | 16:33 |
| th1a | replaceafill: Would you like to start? | 16:35 |
| th1a | Have some news? | 16:35 |
| replaceafill | sure | 16:35 |
| replaceafill | ah yes :) | 16:35 |
| replaceafill | the vice-minister of technology from the ministry of education called me on monday | 16:35 |
| replaceafill | he wants me to give a talk in the ministry about SchoolTool | 16:36 |
| menesis | 8] | 16:36 |
| replaceafill | it seems they're considering doing a small pilot | 16:36 |
| replaceafill | so i'm going to go there next wednesday at 1:30 to meet with them | 16:36 |
| replaceafill | and show them what we've done :) | 16:36 |
| replaceafill | they already have a custom SIS built in Java | 16:37 |
| replaceafill | but who knows ;) | 16:37 |
| replaceafill | i'll keep you all posted | 16:37 |
| replaceafill | my report: | 16:38 |
| replaceafill | could you log in as teacher001 | 16:38 |
| replaceafill | http://69.164.203.135:6661/schoolyears/2011-2012/2012-spring/sections/math_a_2012-spring_teacher001_000/activities/Worksheet/gradebook | 16:38 |
| replaceafill | and click on the "Printable Worksheet" link | 16:38 |
| replaceafill | i've started styling some of the gradebook reports | 16:39 |
| replaceafill | also, you can go to http://69.164.203.135:6661/schoolyears/2011-2012/2012-spring/sections/math_a_2012-spring_teacher001_000 | 16:39 |
| replaceafill | and click on the "Absences" report | 16:39 |
| replaceafill | (those are the two i have so far) | 16:39 |
| replaceafill | with a "grid" style for the table | 16:39 |
| replaceafill | and the header and footer layout kind of similar to Vinny's design | 16:40 |
| replaceafill | th1a, i didn't know what to put on the right of the big section title | 16:41 |
| replaceafill | Vinny has used the school's address | 16:41 |
| replaceafill | all we have is the name, so i was not sure if i should use it | 16:42 |
| th1a | You haven't styled the tables yet, right? | 16:42 |
| replaceafill | no | 16:42 |
| replaceafill | and i used one single letter activity titles | 16:42 |
| th1a | OK. Had me worried. | 16:42 |
| replaceafill | to make the column really narrow | 16:43 |
| th1a | I'm not sure you should start with the gradebooks. | 16:43 |
| th1a | They're the biggest mess by far. | 16:43 |
| replaceafill | hhmmm | 16:43 |
| replaceafill | i agree :) | 16:44 |
| replaceafill | what other reports do we have besides thegradebook's? | 16:44 |
| th1a | That's what we have report registration to discover. ;-) | 16:44 |
| replaceafill | :D | 16:45 |
| th1a | We did just have a very reasonable request for a section roster/timetable report. | 16:46 |
| replaceafill | Student Detail Report | 16:46 |
| replaceafill | Student Report Card | 16:46 |
| aelkner_ | that's a gradebook report | 16:46 |
| aelkner_ | again | 16:46 |
| th1a | We could even just do that from scratch. | 16:46 |
| replaceafill | i think all of them | 16:46 |
| aelkner_ | \i think you're right | 16:46 |
| th1a | Absences by day... | 16:47 |
| replaceafill | the report card does seem complicated | 16:47 |
| aelkner_ | as a a gradebook report | 16:47 |
| th1a | It is only really complicated insofar as you need diagonal headers. | 16:47 |
| th1a | Failures... | 16:47 |
| th1a | We could work together on a section roster. | 16:48 |
| th1a | Just do that from scratch. | 16:48 |
| replaceafill | sure | 16:48 |
| replaceafill | section roster is the list of people enrolled in the section, correct? | 16:48 |
| replaceafill | (sorry for the dumb question) :) | 16:48 |
| th1a | Yes. | 16:48 |
| replaceafill | just want to be sure | 16:48 |
| replaceafill | ah ok | 16:48 |
| replaceafill | ok, we can discuss it after the meeting | 16:49 |
| th1a | This would be one sheet you'd print out for each section that had as much relevant info as we can fit on it. | 16:49 |
| replaceafill | ah ok | 16:49 |
| replaceafill | finally i've been porting some of the gradebook old functional tests | 16:49 |
| replaceafill | to selenium tests | 16:49 |
| replaceafill | i really don't want to break anything in the gradebook :) | 16:50 |
| replaceafill | and yesterday i sent an email to the dev list with an experiment i did | 16:50 |
| replaceafill | hope we get it in the test runner someday ;) | 16:50 |
| * replaceafill done | 16:50 | |
| aelkner_ | i think it would be nice to have a flag for running or not running with chrome popping up | 16:51 |
| replaceafill | +1 | 16:51 |
| aelkner_ | i agree that it is annoying when one want to do other things while the test runs | 16:51 |
| aelkner_ | but i also like seeing the tests | 16:51 |
| replaceafill | definitely | 16:51 |
| aelkner_ | my vote would be for having them visiable by default and have the flag for hiding them | 16:51 |
| aelkner_ | -h? | 16:52 |
| replaceafill | that's it from me th1a | 16:54 |
| th1a | Thanks replaceafill. | 16:54 |
| th1a | Do you want to work on the section reports this afternoon? | 16:54 |
| replaceafill | sure | 16:54 |
| th1a | OK. | 16:56 |
| th1a | yvl: How is history? | 16:57 |
| th1a | Historic? | 16:58 |
| yvl | very much :) | 16:58 |
| yvl | in progress ATM | 16:58 |
| yvl | should be done this week | 16:58 |
| yvl | this will be kind of a short week for me | 16:59 |
| yvl | I only put few hours yesterday, and I'll take the Fri off | 16:59 |
| * yvl wanted historic records to be quite non-intrusive and not bloat the DB at the same time | 17:00 | |
| th1a | And... ? | 17:01 |
| yvl | and that's what I'm doing | 17:02 |
| yvl | btw, replaceafill, thanks for finding the pyvirtualdesktop - precisely what I was searching for | 17:02 |
| replaceafill | :) | 17:02 |
| * yvl admits being too lazy to run under xvfb manually | 17:02 | |
| * yvl done | 17:03 | |
| replaceafill | i've always been interested since i heard you talk about it | 17:03 |
| th1a | OK, thanks yvl. Glad that's coming on schedule. | 17:04 |
| th1a | aelkner_? | 17:05 |
| aelkner_ | ok, i moved the layers and nodes objects out of the school year | 17:05 |
| aelkner_ | if anyone merges with trunk, they'll need to wipe their Data.fs | 17:05 |
| aelkner_ | i didn't bother to create an evolution because we all agreed that there was no real beta tests out there | 17:06 |
| aelkner_ | except for us developers having sandboxes | 17:06 |
| yvl | sure | 17:06 |
| aelkner_ | so i started working on the new document object | 17:07 |
| aelkner_ | as we agreed i'll be creating a IDocumentContainer off of app and put IDocument(INode) objects there | 17:07 |
| aelkner_ | the thing about Document objects is that they are nodes, root notes really | 17:08 |
| aelkner_ | but they just will have an extra attribute called hierarchy | 17:08 |
| aelkner_ | which will be a list of layers | 17:08 |
| yvl | well, whatever floats your boat :) | 17:08 |
| aelkner_ | thanks yvl, i like having a boat that floats :) | 17:09 |
| th1a | It needs to have layers and labels for skillgroups and skills. | 17:09 |
| aelkner_ | yes, th1a, i caught that you wanted them to be able to say 'Add Competency' | 17:10 |
| aelkner_ | so we need the lowest layer to be the name of skills | 17:10 |
| aelkner_ | here's the thing, yvl, i wanted to double-check your original intent | 17:11 |
| aelkner_ | nodes, in any case i can think of, should each have one and only one parent, the root having none | 17:11 |
| aelkner_ | and one and only one layer | 17:11 |
| yvl | no, but do go on | 17:12 |
| aelkner_ | so all nodes that are children of the document would have layer, 'Course' | 17:12 |
| aelkner_ | and those below that, 'Competency Group' | 17:12 |
| aelkner_ | well, what did you intend then? | 17:12 |
| yvl | nodes should have none or one or more parents | 17:13 |
| th1a | Documents are a simplified subset of what the data model allows. | 17:13 |
| th1a | That's kind of the point. | 17:13 |
| yvl | noes should have none or one or more parents | 17:13 |
| yvl | and I still don't see any points in creating extra objects | 17:13 |
| aelkner_ | i still don't see the point of having more than one parent | 17:14 |
| yvl | but if it makes your life easier, please do go on with the implementation | 17:14 |
| th1a | Because nobody will every be able to use this otherwise. | 17:14 |
| th1a | There is a point to having more than one parent. | 17:14 |
| th1a | VA CTE requires it. | 17:14 |
| aelkner_ | how? | 17:14 |
| yvl | jeez | 17:14 |
| yvl | ok | 17:14 |
| th1a | They have nodes with more than one parent! | 17:14 |
| yvl | yes :D | 17:14 |
| aelkner_ | i mean, what is it that they require that we would need more than one parent | 17:14 |
| replaceafill | is that the INDUSTRY vs EDUCATION part? | 17:15 |
| th1a | They have multiple overlapping document structures. | 17:15 |
| th1a | (that's the way I see it) | 17:15 |
| aelkner_ | i don't see a need for overlapping docment structures | 17:15 |
| th1a | My point is that it is necessary, because our primary user requires it. | 17:16 |
| aelkner_ | so if someone else sees that need, by all means show me how | 17:16 |
| th1a | However, it is an uncommon case. | 17:16 |
| yvl | aelkner_, can you please take a look at CTE data and confirm that? | 17:16 |
| th1a | aelkner_: This has been a requirement all along, so drop it. | 17:16 |
| th1a | It is a real, actual requirement. | 17:16 |
| th1a | HOWEVER, | 17:16 |
| th1a | the most common use case is, you're a secretary, with a book of standards, arranged in a hierarchy, and you have to type this shit in. | 17:17 |
| th1a | That's what you're worried about aelkner_. | 17:17 |
| th1a | That has to make sense to a school clerk in San Salvador. | 17:17 |
| th1a | Or a teacher, and ALL of them think of skills as coming packaged as documents. | 17:17 |
| aelkner_ | yeah, i'm with you on that | 17:18 |
| th1a | Documents are to hide our abstractions. | 17:18 |
| aelkner_ | it's a good thing, too, because we don't even have a definition for our abstractions | 17:19 |
| th1a | There isn't a problem with the underlying skills data model though. | 17:19 |
| aelkner_ | so we better hide them :) | 17:19 |
| aelkner_ | and my issue is, i do't know what coding assumptions to make when i don't even see the purpose | 17:19 |
| aelkner_ | of having multple parents/layers | 17:19 |
| *** replaceafill has quit IRC | 17:19 | |
| aelkner_ | i mean, how often do i have to code protectively for those cases, and wy? | 17:20 |
| *** replaceafill has joined #schooltool | 17:20 | |
| aelkner_ | it wou;ld really help, coding it i mean, if i knew what the point was | 17:20 |
| aelkner_ | that way, i could have and if statement, you know like in python and all | 17:20 |
| th1a | Your objective is to hide multiple parents and show the one relevant to the current document context. | 17:20 |
| aelkner_ | al right, here's the scanario | 17:21 |
| th1a | Which, as I said in the original email, you may just do by tracking user navigation. | 17:21 |
| th1a | Remember what parent they came from. | 17:21 |
| th1a | Go back that way. | 17:21 |
| aelkner_ | what parent? | 17:21 |
| th1a | The parent of the node you're looking at. | 17:21 |
| aelkner_ | what if it has more than one? | 17:22 |
| th1a | Keep track of which parent they came from. | 17:22 |
| th1a | Take them back the same way. | 17:22 |
| aelkner_ | how do you keep track? | 17:22 |
| aelkner_ | if i visit a url path/to node/docment.html | 17:22 |
| aelkner_ | what do i know about which parent? | 17:23 |
| yvl | I think this is what you have to solve | 17:23 |
| th1a | Cookie? Session variable? | 17:23 |
| aelkner_ | th1a, no | 17:23 |
| th1a | Traversal magic? | 17:23 |
| th1a | If you go straight to a node, you're not browsing a document. | 17:24 |
| th1a | Show both parents. | 17:24 |
| th1a | If you browse via a document, just remember the path. | 17:24 |
| aelkner_ | if you are looking at a node, there is a Done button, where does it go? | 17:24 |
| th1a | That depends on how you got there. | 17:25 |
| aelkner_ | a url | 17:25 |
| aelkner_ | this is a web server, not a stand-alone app | 17:25 |
| aelkner_ | one can visit a url any time they like | 17:26 |
| aelkner_ | and it has to make sense to deliver the payload | 17:26 |
| aelkner_ | we do this all over the app | 17:26 |
| th1a | If they go straight to the node, take them back to the nodes index. | 17:26 |
| aelkner_ | we NEVER rely on where the user clicked! | 17:26 |
| th1a | aelkner_: If you have a better solution to the problem, fine. | 17:26 |
| aelkner_ | yes, i do | 17:26 |
| aelkner_ | but if i suggest it, you'll reject it, and that's not my fault | 17:27 |
| th1a | If your suggestion does not meet VA CTE's requirements, it is not a solution. | 17:27 |
| aelkner_ | i think it would | 17:27 |
| aelkner_ | my suggestion is this: | 17:27 |
| aelkner_ | nodes can only have one parent | 17:27 |
| aelkner_ | there is no need for an overlapping tree | 17:27 |
| aelkner_ | if they need two trees, fine | 17:28 |
| aelkner_ | they just create two of them | 17:28 |
| aelkner_ | all trees lead to leaves, skilllsets | 17:28 |
| aelkner_ | skillsets can in fact be linked to more than one node | 17:28 |
| aelkner_ | but none of our views would require knowing how to navigate from a skillset to a node | 17:29 |
| aelkner_ | so it wouldn't matter that there is more then one node for a sillset in CTE case | 17:29 |
| th1a | Why? | 17:29 |
| aelkner_ | i can't see why nodes would overlap | 17:29 |
| th1a | You'd still have to navigate from skillsets to multiple parent nodes, right? | 17:29 |
| aelkner_ | if they navigate the nodes tree, they can get to the skillset | 17:29 |
| aelkner_ | they will think they are navigating Courses and Competency Groups | 17:30 |
| aelkner_ | but in fact, they will be navgating nodes | 17:30 |
| aelkner_ | that part of hiding the objects from the user makes sense to me | 17:30 |
| aelkner_ | but the part of having multiple parents does not | 17:30 |
| aelkner_ | and noone has defined a use case where it would be needed | 17:30 |
| th1a | This was all hashed out in VA. | 17:31 |
| th1a | In fact, I did find some more Post-It notes while cleaning my room, and step 1) at the top was "Create a standards document" | 17:32 |
| th1a | And 2) was "Set up levels" | 17:32 |
| th1a | So we've already talked about all this at length. | 17:33 |
| aelkner_ | talking is fun, doing something productive is another matter entirely | 17:33 |
| aelkner_ | here's what i'm going to do | 17:34 |
| th1a | If you navigate directly to a node, do you need to know which parent to go "up" to? | 17:34 |
| aelkner_ | i'm gong to code as if nodes have only one parent | 17:34 |
| th1a | NO YOU ARE NOT. | 17:34 |
| aelkner_ | th1a, of course | 17:34 |
| th1a | What if in that case you just go up to "nodes?" | 17:34 |
| th1a | Why would you expect the application to guess correctly? | 17:35 |
| aelkner_ | for example, /path/to/BasicFuctionalSkills/document.html | 17:35 |
| aelkner_ | there's a url that already works in trunk | 17:36 |
| aelkner_ | it has a list of Competency groups and a Done button | 17:36 |
| aelkner_ | guess what, the Done button knows where to go, funny that :) | 17:36 |
| aelkner_ | if there were more than one parent (again why the fuck would we need that), there would be no way to go up | 17:37 |
| th1a | If you navigate via a document structure to a multi-parent node, where do you think "done" should take you? The parent you came from? | 17:37 |
| th1a | (note also we don't necessarily need "done" at all in this case) | 17:38 |
| aelkner_ | this is a browser, it doesn't require that you get to a url from somewhere | 17:38 |
| th1a | What would the user expect? | 17:38 |
| th1a | Look this would work fine with a query string in the url. | 17:38 |
| th1a | if there is a from_parent= then you go back there. | 17:39 |
| th1a | If not, back up to nodes. | 17:39 |
| aelkner_ | ok, that would work | 17:39 |
| yvl | th1a, maybe we could just change the data model to handle what aelkner_ proposed? | 17:39 |
| replaceafill | couldn't this Done button behave like other links and cancel buttons we have, with a camefrom/back_url attribute? | 17:39 |
| aelkner_ | yvl, thanks for validating that i may have a point | 17:39 |
| aelkner_ | could you address the two non-overlapping trees point i made a moment ago? | 17:40 |
| aelkner_ | i mean, is there really any reason for having overlapping trees? | 17:40 |
| th1a | I see no reason to change at this point. | 17:40 |
| th1a | It should have been brought up a long time ago, and I'm fine with a fricking query string. | 17:40 |
| aelkner_ | there was no reason to bring it up long ago | 17:41 |
| aelkner_ | i remember the discussions, and one thing that was clear from listening was that nothing was rally decided | 17:41 |
| th1a | IT WAS DECIDED. | 17:41 |
| aelkner_ | th1a, you're just trying to frustrate me, aren't you? | 17:42 |
| aelkner_ | i mean, how can you say something is decided and then none can define it? | 17:42 |
| th1a | aelkner_: Do you really think I can't come up with a counter-example, if I try hard? | 17:42 |
| aelkner_ | it doesn't make any sense | 17:42 |
| aelkner_ | if there is a need for overlapping trees, show me an quick simple example | 17:42 |
| aelkner_ | i've been trying to say for a while now | 17:42 |
| aelkner_ | if you have no ability to provide an example, then you don't have anything | 17:43 |
| aelkner_ | again, i ask, why overlapping trees?! | 17:43 |
| th1a | What if you have two documents which are the same nodes re-arranged? | 17:43 |
| aelkner_ | th1a, to answer your question, no i don't believe you can | 17:43 |
| aelkner_ | why would you have that? | 17:44 |
| th1a | What if the revision is reorganization? | 17:44 |
| aelkner_ | revise all you want | 17:44 |
| aelkner_ | you dont need ovelapping trees for that | 17:44 |
| aelkner_ | just a new tree | 17:44 |
| aelkner_ | remember, you made me realize this before | 17:44 |
| aelkner_ | we don't care about the trees more than as a navigation to the skillsets | 17:44 |
| yvl | looking at this discussion, I'm starting to think that it would be fastest to restrict to one parent, one layer relationship | 17:45 |
| aelkner_ | so the user creates any number of trees if they like | 17:45 |
| yvl | as in - fastest to get it working now | 17:45 |
| aelkner_ | yvl, thank you, thank you | 17:45 |
| aelkner_ | glad to see someone is listening | 17:45 |
| th1a | I don't see how it is faster than what we already have working now. | 17:45 |
| th1a | Now we have to add a bunch of new validation, right? | 17:45 |
| aelkner_ | ok, so here's the deal | 17:45 |
| yvl | it's like two places | 17:46 |
| yvl | one for parents "have only one" | 17:46 |
| yvl | on for layers "have only one" | 17:46 |
| *** highvoltage has joined #schooltool | 17:47 | |
| th1a | This is to save us using a query string? | 17:47 |
| yvl | so if that makes things going forwards now, we should consider it | 17:47 |
| yvl | yes, since Node.findPaths will return one path - | 17:47 |
| yvl | as long as we enforce this | 17:47 |
| aelkner_ | yvl, yes, thats enforce it | 17:47 |
| th1a | Skillsets still can have multiple parents? | 17:48 |
| aelkner_ | what i'm trying to do is get this done, and that involves not, i repeat not, overengineering | 17:48 |
| aelkner_ | th1a, skillsets need no parents | 17:48 |
| aelkner_ | tey live alone, isolated, they are the real skill containers | 17:48 |
| aelkner_ | te nodes are for navigating to them | 17:48 |
| aelkner_ | more than one tree could lead to the same skillset, np | 17:49 |
| yvl | so in a way - yes, they can have "multiple parents" | 17:49 |
| th1a | So... how do I navigate to and from? | 17:49 |
| aelkner_ | but the trees need to have integrity | 17:49 |
| yvl | I'm just rephrasing what aelkner_ said | 17:49 |
| aelkner_ | yvl, yes, skillsets have multiple parents in that sense | 17:49 |
| aelkner_ | but, nodes do not | 17:49 |
| th1a | So how do I know which node to navigate to from a skillset? | 17:50 |
| aelkner_ | you never need to, why would you need to do that? | 17:50 |
| yvl | that is a very good question | 17:50 |
| aelkner_ | if you navigate the document, you get to the skillset | 17:50 |
| aelkner_ | but | 17:50 |
| yvl | for example, when you are in a course, and see a skillset | 17:51 |
| th1a | Because I am a normal human navigating my skills document. | 17:51 |
| yvl | and it is used in, say, 20-ish nodes | 17:51 |
| aelkner_ | guys, listen up please, do not interrupt for a second | 17:51 |
| yvl | sure | 17:51 |
| aelkner_ | i already coded these views and they work fine | 17:51 |
| aelkner_ | the user gets to the skillset from navigating the document tree | 17:52 |
| aelkner_ | and yes, i did need to have a next_url querystring | 17:52 |
| aelkner_ | to allow the Done button on the skill view to work | 17:52 |
| aelkner_ | but that was ll | 17:52 |
| aelkner_ | all | 17:52 |
| th1a | That will work for nodes, too. | 17:52 |
| aelkner_ | actuall, the skillset view was not even a skillset view but a node view | 17:53 |
| th1a | Here's another case -- CTE resource puts out a new document every year, but most of the top level nodes don't change. I think it is better to have a node point to multiple documents if it appears in multiple documents. | 17:54 |
| aelkner_ | th1a, if CTE puts out a new document every year, why don't we have them make a new tree | 17:55 |
| aelkner_ | why do we need to overlap this shit, to make our lives more difficult? | 17:56 |
| aelkner_ | it doesn't make their's any simpler | 17:56 |
| th1a | Well, for one thing it makes it clearer which nodes have changed. | 17:56 |
| th1a | If you can look at the child development node and see that it points to the 2005, 2006, 2007, and 2008 documents, that's helpful. | 17:57 |
| th1a | hi highvoltage -- we're in the middle of a small design dispute. ;-) | 17:57 |
| aelkner_ | th1a, i'm curios how it helps them to think about nodes, but go ahead and explain that | 17:58 |
| th1a | We've already made our lives difficult, and you've already implemented the only solution that I can see we need, so I don't understand the problem. | 17:58 |
| highvoltage | th1a: I see :) | 17:58 |
| aelkner_ | we didn't need to make our live difficult, and we still don't | 17:59 |
| aelkner_ | we have objects that can point to each other, that is good | 17:59 |
| highvoltage | th1a: well, if the zentyal guys join... at least they have lots of software experience so they'll understand | 17:59 |
| th1a | OK guys, if stranger's show up, we're all happy on this channel. | 17:59 |
| th1a | strangers. | 18:00 |
| aelkner_ | ok, th1a, i tell you what, i'll take this offline with yvl so you can meet wth others | 18:00 |
| th1a | No, you will not. | 18:00 |
| highvoltage | th1a: (ah, I sent you an email, btw, which I'm already referring too but not sure that you read it) | 18:00 |
| th1a | I saw it but have not read it yet. | 18:00 |
| th1a | The bottom line here is that these documents and how people use them aren't particularly rational. | 18:00 |
| th1a | And sooner or later someone's going to want to do something that you think makes no sense. | 18:01 |
| yvl | th1a, maybe we can just implement the simplest approach now, without changing the underlying model, | 18:01 |
| th1a | So I'm happy to have something flexible enough to accomodate that. | 18:01 |
| yvl | and then return to it this autumn, if need be | 18:01 |
| th1a | I think we should keep what we have and change it if there is a problem. | 18:02 |
| aelkner_ | i don't see a need to change the data model | 18:02 |
| yvl | well, here's the thing - limiting to one parent is not changing that much | 18:02 |
| yvl | is more like | 18:02 |
| aelkner_ | yvl, yes! | 18:02 |
| yvl | ... not implementing all of the features | 18:02 |
| th1a | Let me put it this way. | 18:02 |
| th1a | Somebody someday will probably have to pay money to remove this restriction someday. | 18:03 |
| th1a | Which is stupid considering we've already implemented it without it. | 18:03 |
| yvl | well, we implemented the DM part | 18:03 |
| yvl | not the views | 18:03 |
| yvl | so "removing restriction" means coding extra in the views | 18:04 |
| yvl | I'm just saying, th1a, this might, maybe, be less... | 18:04 |
| yvl | how to phrase it... | 18:04 |
| yvl | investigations on the details on how the views should work | 18:05 |
| th1a | The fact of the matter is that we devoted considerable time to creating this level of flexibility. | 18:05 |
| th1a | So we might as well keep it. | 18:05 |
| th1a | Hiding the flexibility is not so much work. | 18:06 |
| th1a | But if we'd designed this less flexibly it would have been much easier in the first place. | 18:06 |
| aelkner_ | th1a, we don't need to change anything, so i'm not sure what you're referring to | 18:06 |
| aelkner_ | we just never needed the multiple parent thing | 18:07 |
| aelkner_ | so since never needed it, and never will, np | 18:07 |
| th1a | I'm saying, if we were ok making these trees, the whole thing would have been simpler | 18:07 |
| th1a | You don't know that we'll never need it. | 18:07 |
| aelkner_ | YAGNI | 18:07 |
| th1a | And if you thought that, you needed to say so in VA. | 18:07 |
| th1a | We had lengthy, days long design discussions and settled on this design. | 18:08 |
| th1a | We spent extra time to implement it. | 18:08 |
| th1a | And there is no need to paper over it to avoid using a few query strings. | 18:08 |
| th1a | The time for YAGNI was four months ago. | 18:09 |
| aelkner_ | so here's what i'm going to do | 18:13 |
| aelkner_ | each node will have one and only one level, telling us what it is, Course, Competency Group | 18:13 |
| aelkner_ | class Document(Node): | 18:14 |
| th1a | Does each node only have one level now? | 18:14 |
| aelkner_ | we use relationships which are always mant to many, so the data model currently already allows it | 18:15 |
| aelkner_ | yvl, i was going to ask to discuss a singleton relationship property, but that's for another discussion | 18:16 |
| aelkner_ | no time now | 18:16 |
| aelkner_ | however | 18:16 |
| aelkner_ | i need a document object to define what the hierarchy is | 18:16 |
| aelkner_ | another new relationship of document to layers | 18:16 |
| aelkner_ | that list of layers will be the hierachy | 18:17 |
| aelkner_ | since relationships act as dictionaries in that they are hashed | 18:17 |
| aelkner_ | there is no order, so | 18:17 |
| aelkner_ | i will need to count on layers having parents | 18:17 |
| aelkner_ | so if we have Course layer, no parent | 18:18 |
| aelkner_ | Competency Group layer, parent, Course | 18:18 |
| aelkner_ | and a final layer, say, Competency, parent, Competency Group | 18:18 |
| aelkner_ | then is would be possible for the document object to have a hierarchy attribute | 18:19 |
| aelkner_ | that would be a non-ordered list of layers (again hashing means no order) | 18:19 |
| aelkner_ | and i would use the parental relationship of the layers to determine which order they go in | 18:19 |
| aelkner_ | if a layer can have more than one parent, i'm not sure how that would be possible | 18:20 |
| aelkner_ | i mean, i do need to write python, so it has to be possible to calculate | 18:21 |
| aelkner_ | and since it doesn't make sense for there to be multiple parents anyway | 18:21 |
| th1a | aelkner_: Stop. | 18:22 |
| th1a | Here is what you're going to do. | 18:22 |
| th1a | You're going to build on what we did with the skills browser view you just wrote. | 18:22 |
| th1a | You're going to make a very simple document object to define the top layer. | 18:22 |
| th1a | And you're going to use query strings to let people navigate up and down through the documents. | 18:23 |
| th1a | That's all we need. | 18:23 |
| th1a | And we need to let the user define the layers so they can add them in the correct order. | 18:24 |
| th1a | That is all we need. | 18:24 |
| th1a | This entire project is time constrained. We need to keep moving. | 18:25 |
| th1a | We could just drop the entire task for now since VA doesn't really care about it. | 18:27 |
| yvl | ok... | 18:29 |
| aelkner_ | let's let yvl go | 18:30 |
| yvl | a bag of gravel would be appreciated | 18:31 |
| * yvl has some commitments :| | 18:31 | |
| * th1a drops the bag of gravel. | 18:32 | |
| * th1a is on the phone with aelkner_. | 18:32 | |
| yvl | thanks guys | 18:32 |
| replaceafill | thanks everybody | 18:32 |
| yvl | don't hesitate to email if anything | 18:32 |
| aelkner_ | thanks guys | 18:32 |
| th1a | Have a good week/weekend. | 18:32 |
| th1a | Oh, there will be emails. | 18:32 |
| aelkner_ | yvl, thanks, will do | 18:32 |
| *** Lumiere has quit IRC | 19:15 | |
| *** Lumiere has joined #schooltool | 19:18 | |
| *** paulproteus has quit IRC | 19:25 | |
| *** paulproteus has joined #schooltool | 19:30 | |
| * th1a and aelkner_ made up. | 19:31 | |
| replaceafill | :D | 19:32 |
| replaceafill | th1a, i think vinny didn't put the date of the report on the templates, should we keep it? | 21:20 |
| th1a | The date it is printed? | 21:20 |
| replaceafill | yes | 21:20 |
| replaceafill | at the bottom | 21:20 |
| replaceafill | created with school tool, page number, date | 21:21 |
| th1a | We have it currently? | 21:21 |
| replaceafill | yes, we have that format ^ | 21:21 |
| th1a | What are you working on? | 21:21 |
| replaceafill | the new footer :) | 21:21 |
| th1a | Leave it out for now. | 21:22 |
| replaceafill | ok | 21:22 |
| th1a | Is the footer going to keep you busy for a while? | 21:26 |
| replaceafill | hhmm not really, i already finished | 21:26 |
| replaceafill | but i'm adjusting what i've done | 21:26 |
| replaceafill | making it easier to use | 21:26 |
| replaceafill | cleaning, etc | 21:26 |
| th1a | OK, shall we think about a section roster report? | 21:29 |
| replaceafill | sure | 21:29 |
| replaceafill | i still wonder what to put where vinny placed the school info though | 21:29 |
| th1a | Just the name of the school for now I'd think. | 21:29 |
| replaceafill | ah ok | 21:29 |
| th1a | We really should add school address & phone. | 21:30 |
| replaceafill | i think we could attach them as preference attributes to the app | 21:30 |
| replaceafill | app object | 21:31 |
| replaceafill | they're annotations | 21:31 |
| th1a | Yes. | 21:31 |
| th1a | Can you point this person to the colors css sheet? https://answers.launchpad.net/schooltool/+question/197416 | 21:31 |
| replaceafill | oh oh, and the question finally came :D | 21:32 |
| replaceafill | "how do i customize the look/feel?" | 21:32 |
| th1a | This is what we're trying to deal with now: https://answers.launchpad.net/schooltool/+question/197286 | 21:33 |
| replaceafill | ah yes | 21:33 |
| replaceafill | the "poster" part confused me | 21:33 |
| th1a | Me too. | 21:33 |
| replaceafill | i thought he wanted something big to put in a wall or something | 21:34 |
| th1a | That's why lots of follow ups are necessary. ;-) | 21:34 |
| th1a | We immediately get into the classic "how do I identify the section" issue. | 21:34 |
| replaceafill | vinny put the term at the top right | 21:36 |
| replaceafill | that maybe helps | 21:36 |
| th1a | Lets base this off the student profile report. | 21:36 |
| th1a | OK. | 21:36 |
| th1a | Yes. | 21:36 |
| th1a | SECTION ROSTER also in the top bar. | 21:38 |
| replaceafill | kk | 21:38 |
| th1a | I'd say course name should be biggest, and maybe we put instructors at right where the address is? | 21:40 |
| th1a | Also in a bigger font. | 21:40 |
| th1a | Course name(s) | 21:42 |
| replaceafill | yes | 21:42 |
| th1a | Hm... maybe we should let those have the whole width. | 21:42 |
| th1a | Not have two columns. | 21:43 |
| th1a | We'll have to fiddle with the font sizes. | 21:43 |
| replaceafill | ok | 21:43 |
| th1a | I think course and instructors we should just flow to the right. | 21:44 |
| th1a | If there are multiple instructors they can be on one line. | 21:44 |
| replaceafill | something like: http://69.164.203.135:6661/schoolyears/2011-2012/2012-spring/sections/math_a_2012-spring_teacher001_000/activities/Worksheet/gradebook/gradebook.pdf | 21:45 |
| replaceafill | teacher001 | 21:45 |
| replaceafill | that one is using the section title | 21:45 |
| replaceafill | where you want the course | 21:46 |
| replaceafill | but i mean, the layout | 21:46 |
| th1a | Hm.... | 21:46 |
| th1a | This is kind of a mess. | 21:48 |
| th1a | The never ending battle over section identifiers. | 21:48 |
| replaceafill | "and where's the school year"... | 21:49 |
| th1a | That's not a big concern. | 21:49 |
| th1a | Identifying the damn thing is. | 21:49 |
| th1a | Just put the term and year in the header. You don't need the term's start and end dates. | 21:51 |
| replaceafill | ok | 21:51 |
| th1a | Or... just the term title is fine really. | 21:51 |
| replaceafill | ok | 21:51 |
| th1a | mumble grumble | 21:51 |
| th1a | I guess do term | year | 21:52 |
| th1a | Do that for now. | 21:52 |
| replaceafill | kk | 21:52 |
| th1a | OK, so Course(s) titles where Charles Brown now is. | 21:53 |
| th1a | Nothing at right. | 21:53 |
| th1a | Below the course titles, first line is | 21:53 |
| th1a | section title (if any) and then section ID in parenthesis | 21:55 |
| th1a | like: | 21:55 |
| th1a | History A – 1 (history_a_2012-spring_teacher002_000) | 21:55 |
| th1a | Then Instructors: | 21:55 |
| replaceafill | ok | 21:56 |
| th1a | Then the hairball -- we'll need a version of the schedule table. | 21:56 |
| th1a | Actually the design should translate just fine. | 21:57 |
| th1a | Maybe we should just put a check in the periods it meets, | 21:57 |
| th1a | so that gets rid of some spacing issues. | 21:57 |
| th1a | Then we just need a table of students. Last, first, middle, ID. | 21:58 |
| replaceafill | ID from demographics, correct? | 22:00 |
| replaceafill | or username? | 22:00 |
| th1a | Oh... | 22:00 |
| th1a | I guess demographics. | 22:00 |
| replaceafill | ok | 22:01 |
| replaceafill | should the schedule table repeat in each page? | 22:02 |
| th1a | No. | 22:02 |
| replaceafill | ok | 22:02 |
| replaceafill | th1a, i'll go get lunch, i'll try to have the roster ready in the morning to show you | 22:09 |
| th1a | Cool. Thanks. | 22:09 |
| *** ignas has quit IRC | 22:27 | |
| th1a | replaceafill: Can you tell Vinny if we need inches or pixels? | 22:47 |
| replaceafill | th1a, done | 23:00 |
| th1a | Thanks. | 23:01 |
| *** menesis has quit IRC | 23:20 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!