| *** didymo has joined #schooltool | 00:43 | |
| *** Fujitsu has joined #schooltool | 01:14 | |
| *** alga has joined #SchoolTool | 01:49 | |
| *** Fujitsu has quit IRC | 01:51 | |
| *** alga has quit IRC | 04:20 | |
| *** subir has joined #schooltool | 05:51 | |
| *** _lunix_ has joined #schooltool | 06:02 | |
| *** _lunix_ has left #schooltool | 06:03 | |
| *** pcardune has joined #schooltool | 06:33 | |
| *** lisppaste5 has quit IRC | 07:30 | |
| *** lisppaste5 has joined #schooltool | 07:40 | |
| *** pcardune_ has joined #schooltool | 12:35 | |
| *** didymo has quit IRC | 12:41 | |
| *** pcardune has quit IRC | 12:53 | |
| *** subir has quit IRC | 13:33 | |
| *** pcardune_ has quit IRC | 13:50 | |
| *** alga has joined #SchoolTool | 13:58 | |
| *** pcardune has joined #schooltool | 14:01 | |
| *** alga_ has joined #SchoolTool | 14:08 | |
| *** alga has quit IRC | 14:26 | |
| *** alga has joined #SchoolTool | 14:47 | |
| *** aelkner has quit IRC | 15:03 | |
| *** ignas has joined #schooltool | 15:24 | |
| *** mgedmin has joined #schooltool | 16:05 | |
| *** aelkner has joined #schooltool | 16:15 | |
| *** pcardune has joined #schooltool | 16:46 | |
| aelkner | ignas: ayt? | 16:59 |
|---|---|---|
| mgedmin | th1a: hi, have you seen my email? | 16:59 |
| aelkner | mgedmin: since ignas and th1a are not responding to us at the moment, could you try sometihng for me? | 17:00 |
| mgedmin | uh oh | 17:01 |
| aelkner | could you try following this link? | 17:01 |
| aelkner | http://spreadsheets.google.com/ccc?key=pprFfM0k-gZXj1ViAx1GUKg&inv=aelkner@gmail.com | 17:01 |
| aelkner | to see if it lets you | 17:01 |
| mgedmin | "Welcome back, Marius. Before using Google Docs, we need to know a little more about you. Please enter the additional information below. " | 17:01 |
| mgedmin | and then | 17:02 |
| mgedmin | "We're sorry, mgedmin@gmail.com does not have permission to access this spreadsheet." | 17:02 |
| aelkner | i had a feeling | 17:02 |
| mgedmin | "This invitation was sent to aelkner@gmail.com, but you are currently signed in as mgedmin@gmail.com." | 17:02 |
| ignas | yep | 17:02 |
| aelkner | i need to share this doc with ignas, but it's not mine | 17:02 |
| aelkner | it was shred with me by the principal of the school here | 17:03 |
| aelkner | is there a way in google docs to save to one's machine? | 17:03 |
| ignas | duno | 17:03 |
| * mgedmin never used google docs | 17:03 | |
| *** jfluhmann has joined #schooltool | 17:08 | |
| *** pcardune has left #schooltool | 17:09 | |
| *** pcardune has joined #schooltool | 17:09 | |
| *** pcardune has left #schooltool | 17:09 | |
| *** pcardune has quit IRC | 17:09 | |
| *** pcardune has joined #schooltool | 17:09 | |
| aelkner | ignas: I created my own ods file with the first three students and attached it to an email i just sent you | 17:09 |
| *** jfluhmann has left #schooltool | 17:09 | |
| pcardune | so there was funny stuff going on with my client | 17:10 |
| ignas | aelkner: and | 17:10 |
| ignas | ok | 17:10 |
| ignas | reading email ;) | 17:10 |
| ignas | aelkner: i'd advise view and annotations | 17:12 |
| ignas | on top of basicperson | 17:13 |
| aelkner | i'm glad as that seems to have less impact than having many different person objects | 17:13 |
| aelkner | have you done this kind of work for lyceum? | 17:14 |
| aelkner | if so, i'd like to see your example | 17:14 |
| aelkner | brb, my brother just arrived here | 17:15 |
| ignas | aelkner: no, not really, basicperson was initially implemented for lyceum | 17:19 |
| ignas | aelkner: by the way, i'd actually not use annotations, but use a separate top level container for the additional data | 17:44 |
| ignas | linked to persons by person ID | 17:44 |
| ignas | to keep it even more orthogonal | 17:44 |
| aelkner | i'm not sure i understand | 17:45 |
| aelkner | i know that annotations are stored with the object | 17:45 |
| aelkner | so why the need for another container | 17:45 |
| ignas | because annotations are stored with the object | 17:45 |
| aelkner | and? | 17:45 |
| ignas | it couples your extra data closely with the schooltool person object | 17:45 |
| ignas | changing the person object to a different one becomes more difficult in the long term | 17:46 |
| ignas | changing the additional data, or removing the additional data | 17:46 |
| ignas | is more difficult that way as well | 17:46 |
| aelkner | i have to admit i can't visualize the difficulties you suggest | 17:47 |
| aelkner | i mean, annotations are just a dictionary | 17:47 |
| ignas | hmm | 17:47 |
| ignas | most annotations keep a reference back to the object they belong to | 17:47 |
| ignas | to make permissions work for example | 17:47 |
| ignas | so if you let's say want to remove your addons from the system and do not include the module | 17:48 |
| ignas | with extra data | 17:48 |
| ignas | evolution of the person object becomes tricky | 17:48 |
| ignas | because there is a broken object (object without a proper definition in python code available to your zope instance) | 17:49 |
| ignas | that refers to the person | 17:49 |
| ignas | the difference between implementations | 17:49 |
| ignas | is quite small anyway | 17:49 |
| ignas | but i think (i might be wrong) that the more separated different components are | 17:49 |
| ignas | the easier it will be in the future | 17:50 |
| ignas | so if someone will try and migrate person objects to an SQL database | 17:50 |
| ignas | it will be a lot easier if there will be no annotations for example | 17:50 |
| ignas | and being able to disable the additional data | 17:50 |
| ignas | by changing one line in ZCML | 17:50 |
| ignas | makes it for a nicer pluggability overall | 17:51 |
| ignas | because your "plugin" lives in a separate isolated space | 17:51 |
| ignas | that only refers to persons through their __name__'s | 17:51 |
| ignas | an object tree in my humble opinion is not as pluggable as separate "tables" or table like structures | 17:52 |
| ignas | because all the modules live in multiple places (like on every single person) | 17:52 |
| ignas | instead of one place | 17:53 |
| ignas | like top level container | 17:53 |
| ignas | but that's just my opinion | 17:53 |
| ignas | i am sure there are Zope3 programmers that would disagree with me | 17:53 |
| aelkner | um | 17:55 |
| aelkner | i don't understand what you mean by tables | 17:55 |
| ignas | top level containers with only one kind of objects in them | 17:55 |
| aelkner | and modules living in multiple places | 17:55 |
| ignas | like - app['courses'] | 17:55 |
| ignas | so courses are only in app['courses'] | 17:56 |
| ignas | while timetables are in every person and every section | 17:56 |
| aelkner | the thing is, you've been dealing with the schooltool data model for a lot longer than I | 17:57 |
| aelkner | so I can't fully grasp the issues you lay out here | 17:57 |
| aelkner | but i'm happy to follow your suggestion | 17:57 |
| ignas | hmm | 17:58 |
| ignas | let me try to explain it until you understand | 17:58 |
| ignas | i need to explain it a bit more to be sure whether i am thinking right ;) | 17:58 |
| aelkner | understood :) | 17:58 |
| ignas | look at evolve14 in schooltool | 17:58 |
| aelkner | ok | 17:58 |
| ignas | it only evolves person object | 17:58 |
| ignas | from one kind to another | 17:58 |
| ignas | and watch how many different things that are "unrelated" to a person, and are in easy annotations | 17:59 |
| ignas | have to be known and thought about | 17:59 |
| ignas | to modify person object | 17:59 |
| ignas | as in - you only want to fix persons, but suddenly you have to think about calendars, timetables, relationships | 18:00 |
| ignas | if (hasattr(annotation, '__parent__') and | 18:00 |
| ignas | annotation.__parent__ is person): | 18:00 |
| ignas | annotation.__parent__ = new_person | 18:00 |
| aelkner | that's clear | 18:01 |
| ignas | is the part that might not work if the definition for that particular annotation is not in the code base anymore | 18:01 |
| ignas | so that's why i think that plugins should be as separate from schooltool as possible | 18:01 |
| aelkner | and your'e suggesting that i don't use annotations for this reason, right? | 18:01 |
| ignas | yes, i suggest that you can just do something like lyceum does with journals | 18:01 |
| aelkner | and that i create my own person object? | 18:01 |
| ignas | no | 18:01 |
| aelkner | i mean | 18:02 |
| ignas | journals are stored in a separate BTree keyed by section_id | 18:02 |
| aelkner | my own sla_person_extensions? | 18:02 |
| ignas | yes | 18:02 |
| ignas | like app['schooltool.sla.demographics'] | 18:02 |
| aelkner | so, the top level container will only exist here at sla | 18:02 |
| aelkner | so other schooltool sites won't be bothered | 18:02 |
| ignas | so IDemographics(person) will do something like: | 18:03 |
| aelkner | and there will be no need for evolving sla stuff that's not even there | 18:03 |
| aelkner | app['schooltool.sla.demographics'] will contain objects | 18:04 |
| ignas | return app['schooltool.sla.demographics'][person.__name__] | 18:04 |
| aelkner | of type SLADemographics for instance? | 18:04 |
| ignas | yes | 18:04 |
| ignas | you will need a subscriber that removes the demographics data | 18:04 |
| ignas | when person is deleted | 18:04 |
| aelkner | and I will override the adapter for IDemographics | 18:04 |
| ignas | but it's easy to do | 18:04 |
| ignas | or add a | 18:04 |
| ignas | schooltool.sla.interfaces.IDemographics | 18:05 |
| ignas | if you want to | 18:05 |
| ignas | or call it some other name | 18:05 |
| ignas | whichever makes sense | 18:05 |
| aelkner | so I create a package called, let's day, sla.demographics | 18:06 |
| aelkner | my sla buildout includes it | 18:06 |
| aelkner | it has the new object i create | 18:07 |
| aelkner | which has InitBase derivitive to create the container | 18:07 |
| aelkner | also overrides for: | 18:07 |
| ignas | yes, and add an evolution script for old SLA instances if they exist | 18:07 |
| aelkner | 1) BasicPerson views | 18:07 |
| ignas | in schooltool.sla.generations | 18:07 |
| ignas | and not overrides | 18:08 |
| aelkner | no old sla instances yet | 18:08 |
| ignas | i think a separate layer for schooltool.sla | 18:08 |
| ignas | would be good enough | 18:08 |
| aelkner | so I create the layer in my sla package and override the default layer there, right? | 18:09 |
| ignas | look at lyceum | 18:09 |
| aelkner | will do | 18:09 |
| ignas | i think tizard has a layer too | 18:09 |
| ignas | to see how a layer for a school setup is done | 18:09 |
| aelkner | you have the same demographics logic (creating the other container) there, too? | 18:10 |
| aelkner | for person demographics, i mean | 18:10 |
| ignas | no | 18:11 |
| ignas | you see i don't need to ;) | 18:11 |
| ignas | there was no basicperson back when I did lyceum | 18:11 |
| ignas | basicperson *is* lyceum person | 18:11 |
| aelkner | haha | 18:12 |
| aelkner | you cheated | 18:12 |
| ignas | well - during cando sprint in washington | 18:12 |
| ignas | we looked at schooltool.person schooltool.demographics | 18:12 |
| ignas | and decided that basicperson is way better as a default | 18:12 |
| ignas | so i had to refactor lyceum person out of lyceum.person into schooltool.basicperson | 18:12 |
| aelkner | admit it, you cheated :) | 18:13 |
| ignas | :P | 18:13 |
| aelkner | so i'm not messing with basicperson or needing to even crate a new person, so i'm really happy | 18:13 |
| aelkner | it's a good plan | 18:13 |
| ignas | :) | 18:14 |
| ignas | hope it works out | 18:14 |
| aelkner | a question of a different sort: | 18:14 |
| aelkner | when i create sla.demographics package | 18:15 |
| aelkner | is that an ok name for the package? | 18:15 |
| aelkner | that's not my whole question , but... | 18:15 |
| ignas | you mean schooltool.sla.demographics ? | 18:15 |
| ignas | or is your school setup named just plain "sla" | 18:15 |
| aelkner | yes | 18:16 |
| ignas | yes to statement 1 or statement 2? ;) | 18:16 |
| aelkner | schooltool is the package root | 18:16 |
| aelkner | sla is a subpackage | 18:16 |
| aelkner | sibling woth course | 18:16 |
| ignas | oh, ok | 18:16 |
| aelkner | i'm asking not telling :) | 18:16 |
| aelkner | actually, maybe i'm telling about sla | 18:17 |
| aelkner | but asking if that's ok | 18:17 |
| ignas | i think so | 18:17 |
| aelkner | is lyceum a pakage under schooltool? | 18:17 |
| ignas | no | 18:17 |
| ignas | i have initially created it outside of the namespace | 18:17 |
| ignas | i think tizard is not in the schooltool namespace too | 18:18 |
| aelkner | what is tizard? | 18:18 |
| aelkner | another school? | 18:18 |
| ignas | the school Ian Benson is working with | 18:18 |
| aelkner | in the UK | 18:18 |
| ignas | ys | 18:19 |
| ignas | yes | 18:19 |
| aelkner | i don't see a lyceum buildout package | 18:20 |
| aelkner | how does that work? | 18:20 |
| ignas | it's in bzr | 18:20 |
| ignas | lyceum is in bzr too | 18:20 |
| ignas | look in code.launchpad.com/schooltool/ | 18:20 |
| ignas | or somewhere around there | 18:21 |
| aelkner | i'm in http://source.schooltool.org/trac/browser/trunk | 18:21 |
| aelkner | not there? | 18:21 |
| ignas | nope | 18:21 |
| ignas | https://code.launchpad.net/~ignas/schooltool/lyceum herew | 18:22 |
| ignas | or here if you want the buildout https://code.launchpad.net/~ignas/schooltool/lyceum-buildout | 18:22 |
| ignas | though lyceum can be built without buildout | 18:22 |
| ignas | to make it easier to test under buildbot | 18:23 |
| aelkner | ignas: i'd like to keep things as simple for me as possible | 18:27 |
| aelkner | for instance: | 18:27 |
| aelkner | the sla package off of trunk | 18:27 |
| aelkner | has under setup.py, the src dir | 18:27 |
| aelkner | containing schooltool, under which is sla | 18:27 |
| aelkner | so i think that make sla a sibling of course | 18:27 |
| aelkner | or any other schooltool subpackage | 18:28 |
| ignas | sla sibling? | 18:28 |
| ignas | why do you want to split sla into separate parts? | 18:28 |
| ignas | if you want it simple | 18:28 |
| ignas | at least at the moment | 18:28 |
| ignas | you could just have something like | 18:28 |
| ignas | schooltool.stapp2008spring package | 18:29 |
| ignas | https://code.launchpad.net/~ignas/schooltool/schooltool.stapp2008spring | 18:29 |
| ignas | with all the things you need in it | 18:29 |
| ignas | like schooltool.sla.demographics | 18:29 |
| ignas | and schooltool.sla.othercrazystuff | 18:30 |
| ignas | in the same egg | 18:30 |
| ignas | in the same checkout | 18:30 |
| ignas | in the same schooltool/sla/ directory | 18:30 |
| ignas | with 1 make file that runs an sla school | 18:30 |
| ignas | and if you will have the time, or will want to | 18:30 |
| ignas | you will be able to split it off later i think | 18:31 |
| ignas | well - maybe you'd want to do 1 thing differently from schooltool.stapp2008spring | 18:31 |
| ignas | and instead of keeping the main configure.zcml in schooltool/sla/ | 18:31 |
| ignas | keep it in schooltool/sla/app/ | 18:31 |
| ignas | to make a creation of schooltool/sla/ namespace package possible in the future | 18:32 |
| ignas | without changing configuration for old sites | 18:32 |
| aelkner | so, i already have the sla package | 18:36 |
| aelkner | adn i could keep everything in there | 18:36 |
| aelkner | including haveing subpakages for demographics | 18:36 |
| aelkner | as weel as two new objects that sla needs | 18:36 |
| aelkner | NarritiveReportCard | 18:36 |
| aelkner | and CSAP | 18:36 |
| ignas | yes | 18:37 |
| ignas | and i even think that you should | 18:37 |
| ignas | what i am suggesting is - moving configure.zcml from sla to sla.app | 18:37 |
| aelkner | so that's what i mean by simple, no need to think of different SVN packages | 18:37 |
| ignas | for future proofness | 18:37 |
| ignas | yep | 18:38 |
| ignas | what I can do for you even | 18:38 |
| ignas | is to make schooltool.sla a buildout by itself | 18:38 |
| ignas | so you won't need any additional checkouts | 18:38 |
| ignas | just checkout sla and "make run" it | 18:38 |
| aelkner | i already created sla.buildout | 18:39 |
| aelkner | and sla | 18:39 |
| aelkner | sla.buildout brings in sla | 18:39 |
| aelkner | basically i cloned jelkner-buildout | 18:39 |
| aelkner | and jelkner2007 | 18:39 |
| ignas | i see, i just find not having a separate buildout a bit more convenient, but it's up to you | 18:39 |
| aelkner | the less i have to change now, the better i feel | 18:40 |
| ignas | :) | 18:40 |
| aelkner | so that i can get things up and running here | 18:40 |
| aelkner | so, i believe that i know what to do now which is great | 18:43 |
| aelkner | thanks | 18:43 |
| ignas | glad to help ;) | 18:44 |
| *** pcardune has quit IRC | 19:26 | |
| *** wbrady has joined #schooltool | 19:33 | |
| *** wbrady has quit IRC | 20:20 | |
| *** ignas has quit IRC | 21:07 | |
| *** aelkner has quit IRC | 21:10 | |
| *** th1a has quit IRC | 21:19 | |
| *** th1a_ has joined #schooltool | 21:21 | |
| *** jfluhmann has joined #schooltool | 21:39 | |
| *** jfluhmann has left #schooltool | 21:41 | |
| *** alga has quit IRC | 21:49 | |
| *** mgedmin has quit IRC | 21:56 | |
| *** th1a_ has quit IRC | 22:00 | |
| *** alga_ has quit IRC | 22:13 | |
| *** didymo has joined #schooltool | 23:22 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!