IRC log of #schooltool for Wednesday, 2004-07-07

**** BEGIN LOGGING AT Wed Jul 7 11:45:13 2004
-->You are now talking on #schooltool11:45
-->thisfred ( has joined #schooltool12:21
---SteveA is now known as SteveA|way13:51
---Disconnected ().16:55
**** ENDING LOGGING AT Wed Jul 7 16:55:40 2004
**** BEGIN LOGGING AT Wed Jul 7 18:46:36 2004
-->You are now talking on #schooltool18:46
---#schooltool :[freenode-info] please register your nickname...don't forget to auto-identify!
th1aHi Marius.  I was just writing a response to your email.18:51
th1aI forgot to mention the Zope 3 schemas and forms.18:51
th1aIn my initial reply.18:52
th1aI'm not sure _when_ will be the best time to add that code to SchoolTool, however.18:52
th1aI'm guessing it would be very helpful for doing the complex forms needed for results tracking.18:53
th1aBut perhaps not necessary for calendaring, which should probably have relatively simple forms.18:54
mgedminI suspect that the work needed to integrate zope 3 forms with schooltool will be more than the gain of using them, at least initially19:02
SteveAone thing to bear in mind is that there are at least two books on zope 3 being produced, as well as other documentation19:03
th1aNow I'm confused, Marius, because your email made it seem like you thought we should add Zope 3 schemas and forms.19:10
mgedminyes :-)19:13
th1aSo you think we should do it for the long run, but there won't be much immediate payoff.19:14
mgedminI think we should mostly because stevea thinks we should19:14
mgedminand because I understand that reinventing the wheel is not a good idea in general19:14
mgedminI expect some complications because I do not know zope 3 source code inside out19:15
th1aIt does seem like using Zope 3 schemas would be very helpful when people want to quickly write small applications to run on SchoolTool.19:16
mgedminI'm unconditionally in favour of schemas19:16
mgedminit is forms that I have reservations about19:16
SteveAthe forms code is good, but I feel it is still rather immature.19:17
SteveAThe widget code is better than the forms code.19:17
th1aWhat's the difference between widgets and forms?19:17
mgedminI'd also like to know that19:18
SteveAa widget is the UI representation of a field19:18
SteveAa field is an element of a schema19:18
SteveAa form is a particular use of one or more schema's widgets19:18
SteveAfor example, an edit form is a way of presenting the writable fields from a schema as widgets into which values can be entered / amended 19:19
SteveAand then, provided the schema validates, these values can be set in the object that provides the schema19:19
th1aSo the presentation step is least mature?19:20
SteveAI just mailed thomas black again about the dns changes.19:20
SteveAthe presentation part is much less mature than the schema stuff19:20
SteveAI think the "presentation of widgets into a form" stuff is most zope3-specfic19:21
SteveAbut, I haven't used it in a while.  just read the messages on the mailing list, talked to people etc.19:21
mgedminactually, the part where I expect difficulties would be switching to zope publication instead of our own ad-hoc traversal + view lookup code, which is a very thin layer on top of twisted.web19:22
mgedminplus adding all the registries, services, adapters, utilities that zope 3 forms/widgets/views require19:23
mgedminand zcml19:23
th1aDoes all that follow from adding schemas and forms?19:24
th1aOh.  I guess you just said that.19:24
th1aHow much work would adding schemas entail?19:25
mgedminvery little I expect19:26
th1aThe thing is, I don't want to delay the calendaring release, but I'd like the calendaring release to test the architecture we'll be using going forward.19:26
SteveAmgedmin: I may be able to share the code I've been working on for mark's other project which uses zope3 libraries but with a non-zope3-ish application, if that will help.  Would need to talk to mark about it.19:27
th1aWell, this seems like the toughest design decision at this point.19:29
th1aI guess XP would dictate that we shouldn't add stuff until we actually need it.19:30
SteveAI'm particularly keen to see the schooltool event system be replaced with the zope3 event system19:34
SteveAthe zope3 one is simpler, and better thought through19:34
SteveA(I designed it with Jim and others, taking learning from the schooltool event system and also from the older zope3 one)19:35
SteveAand thus, easier to document and develop for19:35
SteveAmaybe we should make two documents19:35
SteveAone for features etc.19:35
SteveAone for desirable refactorings19:36
SteveAthen, we can see how they interact19:36
th1aI suppose we could release a calendar server with a slightly fleshed out version of the current code,19:47
th1awhile doing the Zope 3 work in parallel for the "full" SchoolTool platform.19:47
th1aI've got to run for a few minutes...19:48
th1aAny thoughts about doing those two things in parallel?20:38
th1aAnyhow, your idea for the two documents is probably a good one, Steve, although I don't think I understand the low level issue enough to contribute much.21:06
mgedmin+1 for two documents21:07
mgedminideally a refactoring will be done if it makes one of the actual goals (like calendaring views) easier21:08
th1aCould you start something up on the wiki, Marius?21:10
mgedminI think I'm not the one who should do this21:13
mgedminI did not come up with the ideas for the refactorings21:13
mgedminneither I did come up with use cases for calendaring21:14
th1aWhat do we mean by features in this case?21:14
mgedminin fact, I was looking forward to reading about things to understand the goals more clearly ;)21:14
th1aAre we talking about calendaring features or more internal features of the platform?21:15
mgedminI think it makes sense to talk about calendaring features first21:15
mgedminand see which internal features would make it easy to implement those21:15
th1aOverall that makes sense, but I'm just worried that we need to stablilize the internal features in the same timeframe21:16
th1aif we expect other people do develop new systems on the platform.21:17
th1aI guess regardless I'll be working hard on the calendaring specs next week.21:18
th1aThat may answer more of these questions than I think.21:18
mgedminwhat do you call 'internal features'?21:20
mgedmininternal Python APIs?21:20
mgedminor the RESTive interface?21:20
th1aThe Python API, I suppose.21:21
th1aPerhaps this is less a problem than I think.21:22
th1aI guess switching to the Zope 3 event model might be transparent to the rest of the application, for example.21:23
th1aOr at least that's sorta the idea of OOP.21:23
th1aIf all the refactorings are still implementing the same interfaces, I guess it doesn't make much of a difference to people developing Python apps with SchoolTool.21:24
th1aOn the other hand, it seems like schemas and form generation would be exposed directly to an application developer.21:36
*mgedmin thinks21:36
mgedminso far we were using XP's no-upfront-design, refactor-mercilessly developement style21:36
th1aBut if we're developing a platform, it seems like at some point we have to stabilize it for other developers.21:37
mgedminI'm not entirely sure the current Python APIs are exactly what would be needed by an external Python app based on schooltool21:37
th1aI don't mean external--we need to firm up some terminology21:37
th1afor things like assessment tracking.21:38
th1aWhich should work similarly to a Zope product.21:38
th1aNot part of the core.21:38
th1aEasily replaced.21:38
---SteveA is now known as SteveA|way21:41
th1aWe can't have someone write a whole assessment system and then say "Oh, we're using schemas now."21:41
---SteveA|way is now known as SteveA21:44
---SteveA is now known as SteveA|way22:09
---th1a is now known as th1a|way22:18
---You are now known as mg|aboutToGoHome22:20
---Disconnected ().22:39
**** ENDING LOGGING AT Wed Jul 7 22:39:28 2004

Generated by 2.15.1 by Marius Gedminas - find it at!