| *** alga has quit IRC | 04:07 | |
| *** aks has joined #schooltool | 05:31 | |
| *** menesis has joined #schooltool | 09:34 | |
| *** ignas has joined #schooltool | 09:36 | |
| *** menesis has quit IRC | 09:37 | |
| *** menesis1 has joined #schooltool | 09:37 | |
| *** menesis1 is now known as menesis | 09:37 | |
| *** menesis has quit IRC | 10:53 | |
| *** menesis has joined #schooltool | 10:53 | |
| *** alga has joined #schooltool | 12:05 | |
| *** menesis has quit IRC | 12:49 | |
| *** menesis has joined #schooltool | 12:49 | |
| *** alga has quit IRC | 12:53 | |
| *** aks has quit IRC | 13:17 | |
| *** menesis has quit IRC | 13:22 | |
| *** menesis has joined #schooltool | 14:08 | |
| *** alga has joined #schooltool | 14:12 | |
| *** jelkner has joined #schooltool | 15:12 | |
| *** replaceafill has joined #schooltool | 15:24 | |
| th1a | Happy (belated) birthday jelkner! | 15:28 |
|---|---|---|
| th1a | hi menesis, replaceafill, aelkner. | 15:30 |
| replaceafill | good morning/afternoon | 15:30 |
| aelkner | morning | 15:31 |
| th1a | replaceafill, What's the open video chat Ubuntu is pushing now? | 15:31 |
| menesis | hi. | 15:32 |
| replaceafill | th1a, ? | 15:32 |
| replaceafill | open video chat? | 15:32 |
| th1a | Oh... | 15:32 |
| th1a | Mumble? | 15:32 |
| th1a | Oh, that's just voice. | 15:33 |
| th1a | Anyhow... | 15:33 |
| replaceafill | ah, had never heard of it | 15:33 |
| th1a | OK, we have a couple big things to talk about. | 15:33 |
| th1a | Maybe Ubuntu isn't actually pushing it. | 15:33 |
| th1a | Predominantly: Natty packaging and some questions about how to approach specialized demographic cases, particularly how they work in the Cambodia package. | 15:34 |
| th1a | So, menesis, can you update us on where we are now with packaging? | 15:35 |
| menesis | I have to send an email asking for sponsors again | 15:36 |
| menesis | did not do this last week because of UDS | 15:36 |
| menesis | I don't think I need to update any packages, what is in Maverick is OK | 15:37 |
| th1a | Yes. | 15:37 |
| th1a | Python 2.7? | 15:37 |
| th1a | Is that something they might change on us during the process? | 15:38 |
| menesis | ZTK 1.0 is packaged and the supported versions are python 2.4 - 2.6, not 2.7 | 15:39 |
| th1a | You mentioned Python 2.7 might be in Maverick last week? | 15:39 |
| menesis | I haven't looked at buildbots recently, I think only a couple packages' tests fail | 15:39 |
| menesis | but tests failing does not matter as long as schooltool works | 15:40 |
| menesis | you mean, natty? | 15:41 |
| th1a | Yes, Natty. | 15:41 |
| *** replaceafill_ has joined #schooltool | 15:41 | |
| menesis | I see python2.7 is in maverick already | 15:41 |
| th1a | They aren't going to remove 2.6 though, in Natty? | 15:41 |
| menesis | but not as supported version | 15:41 |
| menesis | don't remember whether I saw any decisions about python versions | 15:42 |
| *** replaceafill has quit IRC | 15:42 | |
| menesis | in UDS discussions | 15:42 |
| *** replaceafill_ is now known as replaceafill | 15:42 | |
| menesis | I only followed a couple sessions, not related | 15:43 |
| replaceafill | test | 15:43 |
| th1a | OK, so this is not really a hot issue, just something you were a little worried about? | 15:43 |
| replaceafill | sorry, got disconnected for a while | 15:43 |
| menesis | I think they are trying to make python2.7 a supported version, there are problems | 15:43 |
| menesis | if there are any problems with zope packages then I will have to fix them | 15:44 |
| menesis | hard to predict | 15:44 |
| th1a | But it sounds unlikely that they'd *remove* 2.6 this cycle. | 15:44 |
| menesis | I am not worried about that now | 15:44 |
| th1a | OK. Fine. | 15:44 |
| th1a | So we just need to send that email. | 15:44 |
| th1a | I would like to be able to report that as done to Mark in the annual report, which should be done in about two weeks. | 15:45 |
| th1a | Or at least mostly done! | 15:45 |
| menesis | ok | 15:46 |
| th1a | Then we can relax a little. | 15:47 |
| th1a | So lets get that email out tomorrow at the latest. | 15:48 |
| th1a | OK, replaceafill, I think it is time for me to send an email to Javier. | 15:49 |
| replaceafill | please! | 15:49 |
| th1a | Give them a little boot. | 15:49 |
| replaceafill | i haven't had response on my report sample request | 15:49 |
| th1a | Yes. | 15:49 |
| th1a | What do you have on your queue then? | 15:50 |
| replaceafill | not much for cambodia | 15:50 |
| replaceafill | i finished the pending items i reported in my last email this week | 15:50 |
| replaceafill | i stored the national exam grades for grade 9 and 12 | 15:51 |
| replaceafill | i'd also like to see the UI fully in khmer | 15:52 |
| replaceafill | because of the spaces | 15:52 |
| replaceafill | but that's not as important as the reports | 15:52 |
| th1a | Yes. | 15:52 |
| replaceafill | (i think) | 15:52 |
| replaceafill | and my last question in that last email was about teachers | 15:53 |
| replaceafill | "from grades 1-6, one teacher teaches all subjects to the class, correct? What about the other grades? How many teachers could a class have?" | 15:53 |
| replaceafill | trying to improve teacher assignment to classes | 15:53 |
| th1a | I'd imagine it works like primary and secondary schools pretty much everywhere. | 15:53 |
| th1a | Specialized by subject in secondary. | 15:54 |
| replaceafill | maybe i could change the teacher forms to allow them to assign the class for the teacher | 15:54 |
| th1a | But yes, an answer would help. :S | 15:54 |
| replaceafill | like we do with the student form | 15:54 |
| replaceafill | definitely | 15:54 |
| replaceafill | and also, if yvl have some time this week, finishing the score refactoring would be great :) | 15:55 |
| replaceafill | i mean in the gradebook | 15:55 |
| replaceafill | the score refactoring allow to insert columns in the gradebook using adapters | 15:55 |
| replaceafill | and you can put the logic of the column in the adapter | 15:55 |
| replaceafill | not in the view (like i currently do in cambodia's case) | 15:56 |
| th1a | Well, yvl is on vacation this week. | 15:56 |
| replaceafill | ah | 15:56 |
| th1a | So you could do that. | 15:57 |
| replaceafill | great! | 15:57 |
| replaceafill | and maybe i can work in el salvador stuff? | 15:57 |
| th1a | Yes. | 15:57 |
| replaceafill | i still have some changes to do to the forms, and some report samples for esaes | 15:57 |
| th1a | And otherwise I'll try to have other stuff for you to work on next week if necessary. | 15:58 |
| replaceafill | ah ok | 15:58 |
| th1a | Also, can you just send an email about using the fixes you made to sample data generation? | 15:58 |
| th1a | So people know what they can do with it. | 15:58 |
| th1a | Just a few sentences. | 15:59 |
| replaceafill | like a way of using sample data generation? what i did is not "a big fix" | 15:59 |
| th1a | Well, just update me on what it actually does at this point. | 15:59 |
| replaceafill | ah ok | 15:59 |
| th1a | I mean, I know what it does in general, but what works now? | 15:59 |
| replaceafill | th1a, question | 15:59 |
| replaceafill | i was thinking of writing a schooltool book for cambodia | 16:00 |
| replaceafill | like a quick tutorial on how to use the customizations i've made | 16:00 |
| replaceafill | i mean, i cannot point them to the full schooltool book | 16:00 |
| replaceafill | because the UI is different | 16:00 |
| th1a | Yes... well, let's hold off on that for the moment. | 16:01 |
| replaceafill | ah ok | 16:01 |
| th1a | I don't want to pour a lot more work into this until we hear back from them. | 16:01 |
| th1a | We don't have to go looking for things to do for them. | 16:01 |
| * replaceafill hopes everything is ok with them... | 16:01 | |
| th1a | Especially since we now know we have thousands of other existing users out there right now. | 16:02 |
| replaceafill | got it | 16:02 |
| th1a | I'm just worried about the constant possibility that someone local might snake us. | 16:02 |
| * replaceafill too | 16:03 | |
| replaceafill | "we went with another SIS" is my worst case scenario | 16:03 |
| th1a | SNAKE - If your skating an object in which only a limited number of people can skate, a snake, or snaker, is the person that seems to have more goes than anyone by jumping the naturally occurring queue | 16:03 |
| *** jelkner has quit IRC | 16:03 | |
| th1a | OK. | 16:03 |
| th1a | Thanks, replaceafill. | 16:04 |
| th1a | aelkner: Did you gain any insight to the problem we discussed last night? | 16:05 |
| aelkner | i poured over schooltool.cambodia, creating my own readme doc about what is done there | 16:05 |
| th1a | Feel free to submit that as a patch if it is might be useful to others. | 16:06 |
| aelkner | for instance, this diagram describes the event flow: | 16:06 |
| aelkner | add schoolyear -> add levels -> add groups A, B, C for | 16:07 |
| aelkner | each new level added | 16:07 |
| aelkner | add courses | 16:07 |
| aelkner | add term -> add sections based on -> add report sheets to sections | 16:07 |
| aelkner | levels and courses based on level of the section | 16:07 |
| aelkner | it's all very custom for cambodia's needs | 16:07 |
| aelkner | defines LevelGroups and SectionEnrollment relationships to do this | 16:08 |
| aelkner | uses LevelCourses from core | 16:08 |
| aelkner | nothing is dne with resources | 16:08 |
| aelkner | ApplicationPreferences is subclassed | 16:08 |
| aelkner | and the derived class instance replaces what schooltool puts ApplicationPreferences | 16:09 |
| aelkner | again, i don't see anything that is useful outside of cambodia | 16:09 |
| aelkner | there are custom demographics fields for students, teachers | 16:10 |
| aelkner | custom views for adding them with tons of formlib magic | 16:11 |
| th1a | Yes... | 16:11 |
| replaceafill | z3c.form | 16:11 |
| aelkner | what a mess it is to use that library | 16:11 |
| replaceafill | framework :D | 16:11 |
| aelkner | rocket science to play tic-tac-toe | 16:11 |
| replaceafill | :)) | 16:12 |
| aelkner | i'm just not seeing the benefits | 16:12 |
| aelkner | nor the portability | 16:12 |
| aelkner | what about all of this is going to end up in core? | 16:12 |
| th1a | Well, separate demographics for different groups will probably. | 16:13 |
| th1a | Separate "Add Student" and "Add Teacher" views. | 16:13 |
| th1a | Which closely relates to what you need, aelkner. | 16:14 |
| aelkner | as they are, they are hard-coded table driven | 16:14 |
| aelkner | the tables being specific to cambodia | 16:14 |
| th1a | Yes, the forms themselves. | 16:14 |
| aelkner | that's all there is, the forms | 16:15 |
| th1a | I'm maybe steering this NIEPA project more towards customization than I originally thought. | 16:15 |
| th1a | But basically, we need to go through the process of doing one of these censuses. | 16:15 |
| th1a | Also, pulling things from Cambodia into core is probably going to be a main goal in our next sprint. | 16:16 |
| th1a | General features. | 16:17 |
| replaceafill | is core going to use level-group by default? | 16:17 |
| th1a | What is level-group? | 16:17 |
| aelkner | it's a relationship | 16:17 |
| replaceafill | i mean, the student is assigned to a group and by default he gets in all the sections that are related | 16:17 |
| replaceafill | gets enrolled | 16:17 |
| aelkner | yes, that will be usefule in core | 16:18 |
| th1a | I would say yes. | 16:18 |
| aelkner | although not the part about hard-coding which groups go with which levels | 16:18 |
| aelkner | again, the general case is not considered yet | 16:18 |
| th1a | Well, it would just be a matter of writing a UI, right? | 16:19 |
| replaceafill | i think so, do in a UI what cambodia does with suscribers and initialization | 16:19 |
| aelkner | yes | 16:20 |
| aelkner | for instance, i wrote a view for setting the section group relationship in schooltool.niepa | 16:20 |
| aelkner | but i didn't commit the change, ust kept the diff, as David is not clamouring for that feature | 16:21 |
| aelkner | now that we fixed the cando bug | 16:21 |
| th1a | OK, so getting to the actual issue aelkner has right now... | 16:21 |
| th1a | do you see how you can apply different demographics just for teachers? | 16:21 |
| aelkner | you mean the hack? | 16:22 |
| th1a | ? | 16:22 |
| aelkner | there's this rocket science zc3.formlib view that hard-codes which fields to present | 16:23 |
| aelkner | based on which group the person belongs to | 16:23 |
| th1a | Ah, right. | 16:23 |
| aelkner | it's completly NOT transportable | 16:23 |
| th1a | So everyone has a big demographics schema which includes all the possible ones, but only some are displayed. | 16:23 |
| th1a | ? | 16:23 |
| replaceafill | actually cambodia only use two additional demographics | 16:24 |
| replaceafill | fields | 16:24 |
| replaceafill | "name in latin" and "nationality" | 16:24 |
| aelkner | that's for teachers and administrators | 16:25 |
| th1a | aelkner needs to track stuff like "education level" for teachers. | 16:25 |
| * th1a is remembering this stuff now. | 16:25 | |
| th1a | So at this point, it is just kind of hardwired. | 16:26 |
| *** ignas has quit IRC | 16:26 | |
| aelkner | employer and academic qualification, too | 16:26 |
| th1a | So when you edit person, it directs you to a different view based on the group? | 16:26 |
| aelkner | yes | 16:26 |
| th1a | But everyone has the same schema? | 16:26 |
| aelkner | no | 16:26 |
| aelkner | the form schema is dynamically created | 16:27 |
| replaceafill | schema as in demographics fields? | 16:27 |
| aelkner | then mapped onto the data inside the form code | 16:27 |
| aelkner | students have custom contacts for instance | 16:27 |
| replaceafill | and grade data | 16:27 |
| aelkner | and the student form has to use a custom FormAdapter | 16:28 |
| th1a | In terms of demographic data. | 16:28 |
| aelkner | to get the contacts to show | 16:28 |
| th1a | I'm happy with the end result. | 16:29 |
| *** ignas has joined #schooltool | 16:29 | |
| replaceafill | in terms of demographics fields, all of them uses the same fields, just the student displays them all | 16:29 |
| th1a | Yes. | 16:29 |
| th1a | I'm ok with that approach. | 16:29 |
| th1a | Because down the road what we can do in SchoolTool core is modify the demographics setup page to allow you to specify which fields are relevant to which core groups. | 16:30 |
| th1a | It is a pretty simple change. | 16:30 |
| th1a | (compared to some of the other possibilities) | 16:30 |
| th1a | See what I'm saying, aelkner? | 16:31 |
| replaceafill | and then the forms should react according to the group? | 16:31 |
| th1a | Basically in each field ask "is the person in a group this field is relevant to?" | 16:31 |
| aelkner | that sounds like a nce feature for down the road | 16:32 |
| aelkner | but what about right now? | 16:32 |
| th1a | Well, essentially that's what Cambodia is doing, except hardwired. | 16:33 |
| th1a | Which you could also do. | 16:33 |
| aelkner | how does that help? | 16:34 |
| aelkner | i mean, i can keep teacher data in custom demo fields | 16:35 |
| aelkner | and i can have a custom form that puts the data there | 16:35 |
| th1a | OK. | 16:35 |
| aelkner | but must i use the rocket science formlib approach? | 16:35 |
| th1a | I gather that was primarily necessary for contacts? | 16:35 |
| aelkner | not exacty | 16:36 |
| replaceafill | the rock science approach is also used for presentation | 16:36 |
| aelkner | there are two fieldsets | 16:36 |
| replaceafill | in the student forms | 16:36 |
| aelkner | it's a completely custom form | 16:36 |
| replaceafill | 3 actually | 16:36 |
| replaceafill | student data, grade data, contact person | 16:36 |
| th1a | I like the completely custom form, it is much more usable. | 16:36 |
| th1a | But that's not what I'm really worried about at this exact second. | 16:37 |
| aelkner | also, the UI is crippled in schooltool.cambodia, most standard views are closed off from user | 16:38 |
| aelkner | does David Ally want the same? | 16:38 |
| th1a | He might eventually. | 16:38 |
| *** menesis has quit IRC | 16:38 | |
| *** menesis1 has joined #schooltool | 16:38 | |
| *** menesis1 is now known as menesis | 16:38 | |
| th1a | But we don't need to rush there. | 16:38 |
| th1a | Also, we're not doing eternal open ended work for David. | 16:38 |
| th1a | So let's just get to the point where we can create these census forms -- without completely recreating half the objects in our database. | 16:39 |
| aelkner | you see, i had a plan for creating the census forms and storing all of the data | 16:40 |
| aelkner | in a simple data structure | 16:40 |
| aelkner | that creates no new object types | 16:40 |
| aelkner | using IAnnotations(app)['schooltool.niepa'] | 16:41 |
| aelkner | I can put any data there I want using PErsistenDict and PersistenList | 16:41 |
| aelkner | and have the forms created in a table-driven fashion | 16:42 |
| th1a | Linked to the existing people and resources? | 16:42 |
| aelkner | without needing any formlib magic | 16:42 |
| aelkner | how would I link to existing resources? | 16:42 |
| th1a | That's what I'm asking you. | 16:42 |
| aelkner | I looked at the resource library, too | 16:42 |
| th1a | We already have teachers and classrooms. | 16:42 |
| aelkner | teachers are persons | 16:43 |
| aelkner | whch have custom demos | 16:43 |
| aelkner | resources have no such ting | 16:43 |
| aelkner | there are three resource content types | 16:43 |
| aelkner | Resource, Location, and Equiptment | 16:44 |
| th1a | Yes. | 16:44 |
| th1a | So we need a customized or extended Location. | 16:44 |
| aelkner | so I create a custom content type in schooltool.niepa? | 16:45 |
| aelkner | class NiepaLocation(location): | 16:45 |
| aelkner | ? | 16:45 |
| th1a | I don't really know what the best way to implement it is, | 16:45 |
| th1a | except that a user should be able to add a location to the system and get the necessary fields, and the census should look at those objects in generating its report. | 16:46 |
| aelkner | again, i'm not seeing how this benefits schooltool core | 16:47 |
| aelkner | we create a custom location in schooltool.niepa | 16:48 |
| aelkner | we have a custom form | 16:48 |
| aelkner | our census reports look for the resultant data in custom resource objects | 16:48 |
| aelkner | how does that benefit schooltool core? | 16:48 |
| th1a | It doesn't necessarily directly. | 16:49 |
| th1a | But it benefits SchoolTool to implement a central use case needed by our customers. | 16:49 |
| th1a | And perhaps encourages us to give resources customizable fields. | 16:50 |
| aelkner | the use case is get the census data into a schooltool instance and get it back out | 16:50 |
| aelkner | where that data goes is not important | 16:50 |
| aelkner | if the form of the data is not recognized outside of the custom package | 16:50 |
| aelkner | what difference does it make wat form that data takes? | 16:50 |
| th1a | We can't ask users to enter the same data twice. | 16:50 |
| aelkner | why would we? | 16:51 |
| th1a | Because we already have locations. | 16:51 |
| th1a | And, as far as I can tell, you're suggesting we create different locations, just for census data. | 16:51 |
| aelkner | no, i'm suggesting we don't need any new content types | 16:52 |
| aelkner | heck the whole of the census form can be kept in one data structure | 16:52 |
| aelkner | that does not need to touch into other parts of the system | 16:53 |
| th1a | But you're still suggesting the user enter locations twice, correct? | 16:53 |
| aelkner | i wasn't suggesting entering locations at all, that was your idea | 16:54 |
| aelkner | classrooms as they are specified on the cencus form | 16:55 |
| th1a | So you're suggesting adding locations in a way that cannot be used by the rest of the system, then. | 16:55 |
| aelkner | the rest of the system? what part of the system can deal with custom locations? | 16:55 |
| aelkner | if we had a system for resource demos | 16:56 |
| aelkner | in core already | 16:56 |
| aelkner | then we could leverage that | 16:56 |
| th1a | Well, you can assign an event to a location, correct? | 16:56 |
| aelkner | if that's what i wanted to do, why? | 16:57 |
| th1a | Well, the thing is that locations are underutilized, | 16:57 |
| th1a | but it isn't like they are stupid or there is no reason for them to be there, | 16:57 |
| th1a | it is just one of our little backwaters. | 16:57 |
| th1a | But if we are going to start routing around them entirely, we might as well remove them from the system. | 16:58 |
| th1a | (you can book locations for events, btw) | 16:58 |
| th1a | Although there's also a kind of redundant free form location field in there too. | 16:59 |
| aelkner | i haven't seen that one yet | 16:59 |
| th1a | I mean, look, it is ok if this leads us to a resource cleanup. | 17:00 |
| th1a | We need that anyhow. | 17:01 |
| aelkner | that would be core work, though | 17:01 |
| * th1a drops the bag of gravel. | 17:01 | |
| * th1a and aelkner will keep chatting. | 17:01 | |
| th1a | Have a great week gentlemen! | 17:01 |
| th1a | menesis: Send that email! | 17:01 |
| th1a | aelkner: That may be ok. | 17:02 |
| replaceafill | thanks everybody | 17:03 |
| th1a | replaceafill: Do you have any thoughts about this conversation? | 17:03 |
| aelkner | th1a, thing is, if there is work that needs to be dne in core | 17:04 |
| aelkner | to make resources more flexible | 17:04 |
| aelkner | for instance, the resource container view in core now assumes the three resource types | 17:04 |
| aelkner | and would not be able to handle a new resource type | 17:04 |
| replaceafill | th1a, i still think pilots should allow us to test stuff and then pull things out to core | 17:04 |
| aelkner | thus making it necessary to subclass the view and change in the custom package | 17:05 |
| th1a | replaceafill: Yes, but we need to be smart about what we might want to use and core and what we'd definitely NOT use in core. | 17:05 |
| replaceafill | true | 17:05 |
| aelkner | for instance, ApplicationPreferences | 17:05 |
| th1a | aelkner: What if we just stuck with three content types and made them each customizable? | 17:05 |
| aelkner | like demos for resources | 17:06 |
| th1a | Yes. | 17:06 |
| aelkner | that makes more sense than creating a new resource content type | 17:06 |
| th1a | OK then. | 17:07 |
| aelkner | so, assuming we already have added resource demos to core | 17:07 |
| aelkner | schooltool.niepa would add the resource demo fields at app init | 17:08 |
| th1a | Yes. | 17:08 |
| aelkner | and the core resource views would know how to handle them | 17:08 |
| th1a | Yes. | 17:08 |
| th1a | We'd also provide sensible defaults in core. | 17:08 |
| aelkner | i can see much benefit in that approach | 17:08 |
| th1a | i.e. what they are now. | 17:08 |
| aelkner | we already have the defaults in core | 17:08 |
| aelkner | and canging them now would be problmeatic | 17:08 |
| aelkner | well, not too bad, i guess | 17:09 |
| th1a | Yes. | 17:09 |
| aelkner | what did you have in mind as far as changing the defaults | 17:09 |
| th1a | I mean, just defaulting to what they are now, not nothing. | 17:10 |
| aelkner | yes, the default location fields are: | 17:10 |
| aelkner | actually, capacity is the only additional field form the base resource | 17:11 |
| aelkner | wich has title, description and notes | 17:11 |
| th1a | Location type. | 17:11 |
| th1a | Which perhaps needs to be changed in some way. | 17:12 |
| aelkner | i see type in the interface, but not in the implementaion | 17:13 |
| th1a | I suspect it is an overly magical implementation. | 17:13 |
| aelkner | class Location(BaseResource): | 17:13 |
| aelkner | """Location.""" | 17:13 |
| aelkner | implements(interfaces.ILocation) | 17:13 |
| aelkner | capacity = None | 17:13 |
| aelkner | i think the implements statement there is a bit dishonest | 17:13 |
| aelkner | in other words, i could see saying location = Location('My class room') | 17:14 |
| aelkner | and verifyObject(location, ILocation) failing | 17:14 |
| aelkner | so that's weird | 17:14 |
| aelkner | btw, the same is not true for Equiptment | 17:15 |
| aelkner | which has type = u"" in its class implementation | 17:15 |
| aelkner | so I guess i just found a bug incore | 17:15 |
| th1a | So basically one task here is digging into resources. | 17:16 |
| th1a | What about the person side? | 17:17 |
| th1a | Staff? | 17:17 |
| aelkner | we can have custom demos set up in schooltool.niepa | 17:18 |
| th1a | That would be something that we intend to merge into core though. | 17:18 |
| th1a | So just keep that in mind. | 17:18 |
| aelkner | can't merge custom demos into core | 17:18 |
| aelkner | besides core already supplies the mechanism for having custom demos | 17:19 |
| th1a | Sorry. | 17:19 |
| aelkner | schooltool.niepa would just deine it's own set | 17:19 |
| aelkner | for the custom purpose it has | 17:19 |
| th1a | I was still on resources. | 17:19 |
| th1a | Spaced out. | 17:19 |
| aelkner | ah, i see | 17:20 |
| * th1a presses reset. | 17:20 | |
| aelkner | yes, so you definitely want to have custom demos for resources in core | 17:20 |
| th1a | Yes. | 17:20 |
| aelkner | and then have them used in schooltool.niepa | 17:20 |
| aelkner | as well as using the already supported custom demos for persons | 17:20 |
| th1a | Or push them to niepa first, but knowing we'll probably get them in core by the next release. | 17:20 |
| th1a | On the person side, why don't you just start by adding the necessary fields to a regular custom demographic schema, | 17:21 |
| th1a | and then maybe next(ish) we'll implement the filtering demo fields by group thing, which will take several steps. | 17:22 |
| replaceafill | th1a, turning some (or all) the demo fields off would be a good feature? | 17:23 |
| replaceafill | i mean, if you don't use them, just turn them all off | 17:23 |
| replaceafill | if you just use 2 just leave those two on, etc | 17:23 |
| aelkner | so we need a content type in core that maps groups to custom demo felds | 17:24 |
| th1a | On a per-group basis? | 17:24 |
| th1a | replaceafill? | 17:24 |
| aelkner | actuall, a relationship might work | 17:24 |
| replaceafill | th1a, or in a simple use case | 17:24 |
| th1a | We'd probably only do this for the built in groups, so you can assume they exist. | 17:24 |
| th1a | A list should work fine. | 17:25 |
| replaceafill | i think for instance of cando virginia users, they see all the demo fields, and the custom ones, they use some default ones and the custom ones | 17:25 |
| th1a | Hiding the default ones? | 17:26 |
| replaceafill | they dont use "language" for instance | 17:26 |
| replaceafill | not all, just the one you dont want to use | 17:26 |
| th1a | They can't be deleted now? | 17:26 |
| replaceafill | ah! :D | 17:26 |
| aelkner | demo fields can be removed | 17:27 |
| th1a | Yes. | 17:27 |
| aelkner | but that would effect all preson objects | 17:27 |
| replaceafill | well, actually removing demo fields is like hiding | 17:27 |
| th1a | replaceafill's point is different. | 17:28 |
| aelkner | i can see benefit in having a group - demo fields relationship | 17:28 |
| th1a | than aelkner's current issue. | 17:28 |
| replaceafill | if you add the field again, the data is still there | 17:28 |
| aelkner | which would be used in the preson edit form | 17:28 |
| replaceafill | never mind, nonsense though of mine ;) | 17:28 |
| aelkner | that's ok | 17:29 |
| aelkner | but if we had such a mechanism in core | 17:29 |
| aelkner | for relating a list of demo fields to a group | 17:29 |
| aelkner | it wouldn't have to be only for teachers and students | 17:29 |
| aelkner | the user could set up the relationship for nay group they wanted | 17:30 |
| aelkner | and the custom package could then set up those relationships in the app init | 17:30 |
| *** ignas has quit IRC | 17:33 | |
| th1a | Yes. | 17:33 |
| th1a | The UI is simpler if we limit the group choices, at least initially. | 17:33 |
| aelkner | how do you mean? | 17:34 |
| th1a | If you're choosing among five options instead of N. | 17:35 |
| aelkner | well, if we add group demos | 17:36 |
| aelkner | then i see having a link from the group view | 17:36 |
| aelkner | 'Demos' | 17:36 |
| aelkner | there, the user would select/deselect from the master list of person demo fields | 17:36 |
| aelkner | but that link would be dependent on the view context | 17:36 |
| aelkner | group context, i mean | 17:37 |
| aelkner | so regardless of what group, you'll see the link | 17:37 |
| th1a | I would come at this from the demo interface -- choose groups. | 17:37 |
| th1a | I'm not strongly against just using all groups. | 17:38 |
| aelkner | so, stepping back a second, where are talking about two things: | 17:44 |
| aelkner | 1) group relationship to demos so that schooltool.cambodia wouldn't have needed a custom student form | 17:45 |
| th1a | Well... | 17:45 |
| aelkner | in the first place and schooltool.niepa could have different custom demos for staff | 17:45 |
| aelkner | 2) resource demos | 17:45 |
| th1a | Something like Cambodia, and maybe NIEPA is potentially different, if we're talking about a large scale. | 17:46 |
| th1a | For Cambodia I want a hand-coded custom form to maximize usability. | 17:46 |
| aelkner | well, the custom contacts part of it is cambodia only, i see that | 17:46 |
| aelkner | but as for the rest of the fields | 17:46 |
| aelkner | those that represent the demos | 17:47 |
| th1a | But in core we need to get to "Add Student" which has student-relevant fields, "Add Teacher" which has teacher relevant fields. | 17:47 |
| aelkner | would be automatically generated into the form (no need for cambodia to do it) | 17:48 |
| aelkner | based on the group | 17:48 |
| aelkner | that is, if that feature existed in core | 17:48 |
| th1a | Yes. | 17:48 |
| aelkner | btw, since IDemographics(person_object) is how we get the demo fields in our code | 17:49 |
| aelkner | all we need to do is change the adpater to take the group relationship into acount | 17:49 |
| th1a | Yes. | 17:50 |
| aelkner | also, the adapter would basically be able to handle the person belonging to multiple groups by doing | 17:50 |
| aelkner | a union of the demo fields | 17:50 |
| aelkner | of each group the user belongs to | 17:50 |
| th1a | Yes. | 17:51 |
| aelkner | as the person joins or leaves a group, the form will look different | 17:51 |
| aelkner | and what replaceafill sadi before | 17:51 |
| aelkner | said | 17:51 |
| aelkner | about the values coming back is true | 17:51 |
| th1a | Yes... that's tricky. | 17:52 |
| aelkner | but that's not necessarily a bad thing | 17:52 |
| aelkner | is it? | 17:52 |
| th1a | We could also just display any values that were not none. | 17:52 |
| aelkner | right | 17:52 |
| th1a | You don't really want data disappearing without explanation. | 17:52 |
| aelkner | it's the old hidden versus removing paradigm that we use in the gradebook | 17:53 |
| th1a | Even then, you don't necessarily want things to hide themselves in a way that might seem magical. | 17:53 |
| aelkner | well, if an administrator choses to remove a demo field, they want it removed, right? | 17:54 |
| aelkner | and if they say, woops | 17:55 |
| aelkner | then they should be able to add it back and have the data come back | 17:55 |
| aelkner | that's all i'm saying | 17:55 |
| th1a | I'm referring to if you change someone's group. | 17:55 |
| th1a | And data about them disappears. | 17:55 |
| th1a | And there is no way to get it back except adding them to the group again. | 17:56 |
| aelkner | i'm thinking you would expect the data to disappear if you are using the group demo filter | 17:56 |
| th1a | The end user doesn't know about that. | 17:56 |
| th1a | I'm just saying, we might want to show non-empty fields. | 17:57 |
| aelkner | at the end of the form in a separate fieldset, right? | 17:57 |
| th1a | Perhaps. | 17:58 |
| Lumiere | 'morning everyone (from Bright, Warm, and Sunny Denver) | 18:06 |
| th1a | Hey. | 18:06 |
| aelkner | hey Lumiere | 18:09 |
| Lumiere | how's schooltool doing? | 18:10 |
| Lumiere | I'm planning to visit welsh'/elkner friday | 18:10 |
| th1a | We're huge in Portugal. | 18:10 |
| th1a | http://www.tuttlesvc.org/2010/10/schooltool-critical-links.html | 18:11 |
| Lumiere | very cool | 18:13 |
| *** alga has quit IRC | 18:41 | |
| *** replaceafill has quit IRC | 19:13 | |
| *** menesis has quit IRC | 20:24 | |
| *** alga has joined #schooltool | 21:22 | |
| *** menesis has joined #schooltool | 21:47 | |
| *** menesis has quit IRC | 21:54 | |
| *** menesis has joined #schooltool | 21:55 | |
| *** replaceafill has joined #schooltool | 23:01 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!