| **** BEGIN LOGGING AT Fri Nov 26 09:06:36 2004 | ||
| -->You are now talking on #schooltool | 09:06 | |
| ---Topic for #schooltool is http://schooltool.org | 09:06 | |
| ---Topic for #schooltool set by Aiste at Mon Oct 18 10:47:26 2004 | 09:06 | |
| ---pere_poff is now known as pere | 10:08 | |
| -->thisfred (~thisfred@a213-84-57-72.adsl.xs4all.nl) has joined #schooltool | 11:04 | |
| -->bskahan (~bskahan@dsl093-119-225.blt1.dsl.speakeasy.net) has joined #schooltool | 15:16 | |
| -->tvon|x31 (tvon@dsl093-119-225.blt1.dsl.speakeasy.net) has joined #schooltool | 15:37 | |
| th1a | tvon & bskahan: we've got a little presentation going on here... can we put this off a bit? | 15:54 |
|---|---|---|
| th1a | 15 minutes or a half hour? | 15:54 |
| tvon|x31 | Sure | 15:56 |
| -->bskahan_ (~bskahan@dsl093-119-225.blt1.dsl.speakeasy.net) has joined #schooltool | 15:58 | |
| ---bskahan_ is now known as bska|latop | 15:59 | |
| ---bska|latop is now known as bska|laptop | 15:59 | |
| th1a | There's also a sprint going on here on version control. | 16:00 |
| th1a | We're getting a little taste of that. | 16:00 |
| tvon|x31 | nice | 16:03 |
| tvon|x31 | It's been a hot topic in the GNOME world lately, we've been discussing it a bit here as well | 16:03 |
| bska|laptop | talking about bazaar? | 16:04 |
| th1a | Yeah. | 16:04 |
| th1a | OK. Marius and I are going to multitask. | 16:20 |
| *mgedmin nods | 16:20 | |
| bska|laptop | ok | 16:22 |
| tvon|x31 | Allright | 16:22 |
| th1a | So I guess you guys read over Marius's comments. | 16:23 |
| bska|laptop | yeah, thanks for doing that mgedmin | 16:23 |
| th1a | mgedmin just went to the can. | 16:23 |
| th1a | So anyhow... | 16:24 |
| th1a | 16:24 | |
| th1a | In the meantime, we did resolve the Zope 3 question. | 16:24 |
| bska|laptop | what's the conclusion? | 16:25 |
| tvon|x31 | Whats the verdict? | 16:25 |
| th1a | POV is going to start working on the transition to Zope 3. | 16:25 |
| tvon|x31 | Very nice | 16:25 |
| *bska|laptop nods | 16:25 | |
| th1a | We're also going to focus on creating a calendaring library for Zope 3. | 16:25 |
| th1a | Well, not focus on it, | 16:26 |
| th1a | but get it done. | 16:26 |
| bska|laptop | it makes sense | 16:26 |
| tvon|x31 | Also very nice | 16:26 |
| th1a | Raise our profile in the community. | 16:26 |
| tvon|x31 | Definately | 16:26 |
| bska|laptop | and get the calendar lots of eyes | 16:26 |
| tvon|x31 | That is one of the big reasons I wanted the z3 move to happen | 16:26 |
| th1a | Yeah. I feel much better now. | 16:26 |
| th1a | The future is more clear. | 16:27 |
| tvon|x31 | So for UI work we should focus on this being in z3 then? | 16:27 |
| th1a | Well, I don't think the UI work will be affected. | 16:27 |
| bska|laptop | what's the thought on the timeframe? | 16:27 |
| th1a | mgedmin: how far do you think you'll get in three weeks? | 16:28 |
| mgedmin | good question | 16:28 |
| th1a | We went over the roadmap with SteveA, so we know what direction we're going. | 16:29 |
| th1a | We haven't done time estimates yet. | 16:29 |
| mgedmin | estimating the changes will be difficult | 16:29 |
| mgedmin | I haven't talked about the simplified Zope 3 bit with Jim yet either | 16:30 |
| SteveA | guys, don't think of "zope 3" as being what zope 3 is like when you install and run it | 16:30 |
| SteveA | we'll be using just some selected parts of the zope 3 framework | 16:30 |
| tvon|x31 | Isn't that what we are doing now? | 16:30 |
| SteveA | just, a lot more than we have been before | 16:30 |
| tvon|x31 | ah | 16:30 |
| SteveA | this will result in a net reduction in the amount of code in schooltool | 16:30 |
| bska|laptop | maybe outline the roadmap for us. | 16:31 |
| th1a | http://www.schooltool.org/bounties/z3/Phase1 | 16:31 |
| th1a | Some notes there. | 16:31 |
| SteveA | because some things that are done specially in schooltool will be done using zope 3 facilities instead | 16:31 |
| bska|laptop | http, authentication, | 16:31 |
| bska|laptop | looking at the page now | 16:32 |
| tvon|x31 | turning students/teachers into roles with principal annotations? Or is that further than we want to go? | 16:33 |
| bska|laptop | ok | 16:34 |
| th1a | We didn't discuss that. | 16:34 |
| *tvon|x31 nods | 16:34 | |
| th1a | So the SchoolTool application will work pretty much the same way in the medium term. | 16:35 |
| *bska|laptop nods | 16:35 | |
| th1a | Eventually we might be able to make it work more like an add on to a regular Zope 3 server. | 16:36 |
| bska|laptop | the point is less to 'make it a zope3 app' than to 'reduce duplicate effort' | 16:36 |
| th1a | But not initially, partly because of ongoing changes in Z3. | 16:36 |
| *tvon|x31 nods | 16:36 | |
| tvon|x31 | so we are moving in a direction then | 16:36 |
| th1a | Yes. | 16:36 |
| th1a | Inexorably. | 16:37 |
| th1a | OK, so do you have any specific questions about Marius's comments? | 16:38 |
| bska|laptop | no, most of them were attention to detail things that we should have caught ourselves | 16:38 |
| bska|laptop | I have replies to speific ones that I'll put on the list | 16:38 |
| th1a | OK. | 16:39 |
| th1a | SteveA suggested that you guys might try pair programming. | 16:39 |
| *bska|laptop nods | 16:40 | |
| bska|laptop | I find it helpful, Tom's not as convinced | 16:40 |
| tvon|x31 | We'll give it another shot this time around | 16:40 |
| bska|laptop | I think its a control freak thing ... | 16:41 |
| tvon|x31 | so anyways... | 16:41 |
| th1a | I haven't tried it myself, so I don't have any insight. | 16:41 |
| tvon|x31 | :) | 16:41 |
| th1a | Also, mgedmin was showing me a different method of doing tests. | 16:42 |
| tvon|x31 | oh? | 16:42 |
| th1a | What was that URL, mgedmin? | 16:42 |
| mgedmin | just a sec | 16:42 |
| mgedmin | http://dirtsimple.org/2004/11/stream-of-consciousness-testing.html | 16:42 |
| mgedmin | I'm not suggesting that we should forget all about unit tests and start using doctests exclusively | 16:42 |
| mgedmin | but there are definitely cases where doctests are much more easier to read than unit tests | 16:43 |
| *mgedmin would like to briefly talk about dynamic schema facets | 16:44 | |
| tvon|x31 | Alright | 16:44 |
| SteveA | doctests are very very good things | 16:45 |
| *mgedmin agrees | 16:45 | |
| mgedmin | why do you need IDynamicSchemaFacetService? | 16:45 |
| mgedmin | would IDynamicSchemaService be enough? | 16:45 |
| bska|laptop | mgedmin: that was a refactoring error on my part | 16:46 |
| mgedmin | so there should be only one of those two, right? | 16:46 |
| mgedmin | which one? | 16:46 |
| tvon|x31 | right | 16:46 |
| bska|laptop | I was adding IDynamicRelationshipSchemaService for dynamic relationships | 16:46 |
| mgedmin | I see | 16:46 |
| mgedmin | maybe | 16:46 |
| bska|laptop | I removed them last week because they needed non-binary relationships | 16:47 |
| bska|laptop | the thought proccess was to keep separate services for relationship schema vs. facet schema | 16:48 |
| mgedmin | would they both use IDynamicSchema in some way? | 16:48 |
| mgedmin | I do not understand | 16:49 |
| mgedmin | the way I see it, IDynamicSchema is a list of fields | 16:49 |
| tvon|x31 | yes | 16:49 |
| mgedmin | and I do not see how that pertains to relationships | 16:49 |
| mgedmin | anyway, let's not get distracted | 16:49 |
| mgedmin | since dynamic relationships are not present in the subversion repository | 16:50 |
| mgedmin | I'll pretend that they do not exist ;) | 16:50 |
| *bska|laptop nods | 16:50 | |
| mgedmin | what is the default dynamic schema used for? | 16:50 |
| mgedmin | is it used for anything? | 16:50 |
| bska|laptop | no, it can (and should) be removed | 16:51 |
| mgedmin | ok | 16:51 |
| mgedmin | where does IDynamicFacet store data? | 16:51 |
| mgedmin | inside fields? | 16:51 |
| tvon|x31 | in fieds in a facet. the dfacetservice stores templates for factes. when they are added to an object the object gets an empty copy of the facet | 16:53 |
| mgedmin | ok | 16:55 |
| mgedmin | so conceptually you can create a facet | 16:55 |
| mgedmin | and then alter its fields | 16:55 |
| mgedmin | e.g. add a new field | 16:55 |
| mgedmin | in other words, two objects that both have contact-info facets may in fact have different sets of fields in them | 16:56 |
| mgedmin | no? | 16:56 |
| tvon|x31 | no, you can only edit the template facet | 16:56 |
| tvon|x31 | actually, there are no restrictions in the code that prevent you from editing a copy of hte facet that lives on an object (now that I think about it), but there should be | 16:57 |
| mgedmin | ok | 16:57 |
| mgedmin | it would be clearer if that restriction was also reflected in the interfaces | 16:57 |
| *tvon|x31 nods | 16:58 | |
| mgedmin | IDynamicSchemaField: I do not really understand this interfaces | 16:58 |
| mgedmin | s/interfaces/interface/ | 16:58 |
| mgedmin | it is basically a dict | 16:58 |
| mgedmin | can I store arbitrary keys and values in a field? | 16:58 |
| mgedmin | are there any predefined keys that have special semantics? | 16:58 |
| tvon|x31 | yes, I'll add that to the interface as well | 16:59 |
| *mgedmin is confused | 16:59 | |
| mgedmin | what will you add to the interface? | 16:59 |
| tvon|x31 | it is basically a dict with specific keys | 16:59 |
| tvon|x31 | wait a second | 17:00 |
| *mgedmin would really like fields to store things like its name and type in attributes rather than in items with special keys | 17:01 | |
| tvon|x31 | The field has basic keys, name, label, value, ftype (field type) and vocabulary (for selection fields). | 17:01 |
| tvon|x31 | they are, it's just accessed like a dict | 17:01 |
| mgedmin | why? | 17:01 |
| mgedmin | it's not pythonic | 17:02 |
| tvon|x31 | so in tal you can do field/value or field/label | 17:02 |
| tvon|x31 | that was my thinking anyways | 17:02 |
| mgedmin | you can do the same with attributes | 17:02 |
| tvon|x31 | ah | 17:02 |
| mgedmin | we usually build dicts in view code for page templates | 17:02 |
| mgedmin | because building objects with arbitrary attributes is difficult | 17:02 |
| mgedmin | and defining a new class is overkill | 17:03 |
| mgedmin | but when you already have a class | 17:03 |
| mgedmin | its attributes are perfectly accessible to page templates | 17:03 |
| tvon|x31 | understood | 17:03 |
| tvon|x31 | I'll rewrite it with methods like get/setLabel, get/setValue etc | 17:04 |
| mgedmin | please dont! | 17:04 |
| mgedmin | this is not java | 17:04 |
| tvon|x31 | oh? | 17:04 |
| mgedmin | why use accessor methods when you can simply use attributes | 17:04 |
| tvon|x31 | You are saying to access the attributes directly? or use property()? | 17:05 |
| mgedmin | use attributes unless you need some special magic | 17:05 |
| mgedmin | by special magic I mean, eg., making that attribute read-only | 17:05 |
| mgedmin | or computing its value on the fly | 17:05 |
| tvon|x31 | right | 17:05 |
| mgedmin | or taking some action with side effects when the value of the attribute changes | 17:05 |
| mgedmin | it is perhaps better to continue the design session via email | 17:06 |
| mgedmin | where we could pass code snippets to each other | 17:06 |
| mgedmin | it is difficult to do over irc | 17:06 |
| tvon|x31 | sounds good | 17:06 |
| mgedmin | perhaps I propose a design that seems clean and pythonic to me | 17:06 |
| mgedmin | and then you can tell me if that design is workable | 17:07 |
| tvon|x31 | question though, if the class is basically an __init__ and a few attributes, what should the interface look like? | 17:07 |
| mgedmin | to achieve the features that you need | 17:07 |
| tvon|x31 | that works | 17:07 |
| mgedmin | if your class is just a collection of data | 17:07 |
| mgedmin | the interface should just contan a bunch of attribute declatations | 17:07 |
| tvon|x31 | ah | 17:07 |
| mgedmin | your IAddressFacet is a perfect example | 17:07 |
| *bska|laptop nods | 17:07 | |
| bska|laptop | there's a few others like that | 17:07 |
| mgedmin | actually, now that we are moving towards Zope 3 | 17:08 |
| mgedmin | it would be better to use zope.schema fields rather than plain Attributes | 17:08 |
| tvon|x31 | yeah | 17:08 |
| mgedmin | e.g. name = TextLine(title="Name", description="The name of the person") etc. | 17:08 |
| *bska|laptop nods | 17:08 | |
| mgedmin | in fact, perhaps you could replace DynamicFacetFields with instances of zope.schema fields? | 17:08 |
| mgedmin | but that is a more significant refactoring | 17:09 |
| mgedmin | that can wait until later | 17:09 |
| mgedmin | i would like to clean up the existing interfaces first | 17:09 |
| tvon|x31 | yeah | 17:09 |
| tvon|x31 | I'll have to look at zope.schema, it might obsolete DSField in the long run anyways | 17:10 |
| mgedmin | ok, then I'll go and compose that email | 17:10 |
| tvon|x31 | Allrighty | 17:10 |
| bska|laptop | th1a: what's next on the agenda? | 17:11 |
| th1a | A nap. | 17:13 |
| th1a | I think that covers things. | 17:13 |
| th1a | We've been talking about UI use cases, too. I started putting up a wiki page for that in the bounty section. | 17:14 |
| tvon|x31 | ah, good | 17:14 |
| th1a | We don't need to discuss it now, though. | 17:14 |
| tvon|x31 | In that case, I think we are going to go get lunch. | 17:15 |
| bska|laptop | when do you want to start the next set of stories? | 17:15 |
| th1a | Writing them? | 17:15 |
| bska|laptop | working on them | 17:16 |
| bska|laptop | I'll write something to start passing back and forth this weekend | 17:16 |
| th1a | OK, cool. | 17:17 |
| th1a | I won't be able to spend much time on it until Tuesday. | 17:18 |
| th1a | But we should be able to get it done Tuesday/Wednesday. | 17:18 |
| bska|laptop | sounds good | 17:18 |
| bska|laptop | I'm going to start with the notes from last week, send me anything that comes up | 17:19 |
| th1a | OK. I'll try to throw some things together. | 17:19 |
| bska|laptop | as we're going trhough marius' comments, should we commit changes on those thngs to the rc1 branch as well as trunk? | 17:20 |
| mgedmin | I do not think so | 17:22 |
| bska|laptop | ok | 17:22 |
| mgedmin | I think only important bug fixes should be committed to the branch | 17:22 |
| bska|laptop | allright, we'll commit to trunk unless something appears to break functionality | 17:23 |
| bska|laptop | th1a: we're going to grab lunch if there's nothing else | 17:33 |
| ---pere is now known as pere_poff | 17:38 | |
| *mgedmin sent the email | 17:43 | |
| <--thisfred has quit ("Farewell, cruel channel...") | 17:54 | |
| <--bska|laptop has quit (Read error: 110 (Connection timed out)) | 18:46 | |
| <--SteveA has quit ("Leaving") | 18:50 | |
| <--th1a has quit () | 18:51 | |
| SysTray Integration Plugin unloaded | 18:51 | |
| Python interface unloaded | 18:51 | |
| Tcl interface unloaded | 18:51 | |
| **** ENDING LOGGING AT Fri Nov 26 18:51:48 2004 | ||
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!