IRC log of #schooltool for Wednesday, 2005-08-24

povbot/svn/commits: * srichter committed revision 4853:00:44
povbot/svn/commits: Grammar fixed.00:44
povbot/svn/commits: * srichter committed revision 4854:00:45
povbot/svn/commits: Converted tests to testbrowser. I think I am done now; it's getting too boring.00:46
*** tvon has quit IRC01:00
*** tvon has joined #schooltool01:01
*** tiredbones has quit IRC01:17
*** alga has quit IRC03:18
*** tvon has quit IRC09:35
*** tvon has joined #schooltool10:09
*** th1a has joined #schooltool13:34
srichterokay, I am here now :-)14:21
th1aOkay, I am sitting outside of POV again.14:22
*** alga has joined #SchoolTool14:32
*** ignas has joined #schooltool14:32
*** alga has quit IRC14:53
*** alga has joined #SchoolTool14:56
*** bskahan has joined #schooltool15:07
th1asrichter:  alga and mgedmin aren't here yet.15:29
bskahan(or afternoon)15:31
th1aGood morning.15:31
bskahansorry I missed monday's meeting, didn't realize it was happening15:31
th1abskahan:  Did you get that email to the guy at The Neighborhood School that I cc:ed you on?15:31
bskahanth1a: yes, I looked up his school, its an elementary school in the village/lower east side15:32
th1abskahan:  It is ok.  I wasn't online Fri.-Sun. and I didn't think to send out an announcement on Thursday.15:32
th1aYeah.  You should send him an email.  I heard back from him shortly thereafter, and he had just found out that their lab had been broken into and an undetermined amount of stuff was stolen.  So that sorta pushed ST deployment off his plate.15:32
*** alga has quit IRC15:36
th1aI suppose I should try to call alga...15:38
th1aIn other news, Helen reports that the meeting in San Francisco went quite well.15:38
th1aThe others will be here in about five minutes.15:39
srichterth1a: so what came out of the meeting?15:39
th1aUh... plans for more meetings!15:40
th1aWhat else comes out of meetings?15:40
srichterhe he15:40
th1aSeriously, though, nothing definite.15:40
srichterI thought something concrete15:40
srichtersomething that lets us evaluate our position in the market15:41
*** tvon has quit IRC15:41
srichteror the chances of getting aone ;-)15:41
th1aThis was the first time any of the actors had gotten together to discuss things in depth, so nobody was expecting anything concrete.15:41
th1aWell, let's put it this way.  The Stupski Foundation is going to make a decision about whether or not they're going to go ahead with their plans.15:42
th1aAnd if so, we'll have to start thinking about how this project might be governed to incorporate more than one Foundation.15:43
srichterI see15:43
th1aThey're expecting to make a decision in about two weeks.15:43
srichterare they particularly looking at SchoolTool?15:43
th1aI'm going to get a coke.  alga and mgedmin just arrived.15:44
th1aThere's no real oss competition.15:44
*** mgedmin has joined #schooltool15:44
*** alga has joined #SchoolTool15:50
th1aSo I figure we should discuss this stuff briefly on IRC to get input from those of us who aren't here physically, about a half hour.15:53
th1aAnd the we'll draft the proposal offline, since I have taken the trouble of actually coming to Lithuania.15:53
th1aSo, let's go over the points of my very rough update of the previous proposal.15:54
th1aStephan has taken care of the code rearranging.15:55
th1aIs there anything outstanding that will need to be done to finish that task?15:55
th1aOther than reviewing the work?15:55
th1aAnd making it the new trunk?15:55
mgedminquestion: are all the bugfixes in the trunk merged to the branch?15:55
srichterI am currently writing an evolution script15:56
srichterno, not yet15:56
srichter(it was not part of my proposal, but once I am done with the evolution script, I am planning to do this part)15:56
srichter(at leaast as far as I get)15:56
mgedminok, so there are two more outstanding issues: db backwards compatibility & merging all the bugfixes15:56
algashouldn't we merge Stephan's work to trunk instead?15:57
th1aBut after Stephan is done, that pretty much completes the grand reorganization phase.15:57
srichteralga: good luck :-)15:57
srichterth1a: yes15:57
srichteralga: no seriously, too much has been moved15:58
algaso, we're swapping trunk instead?15:58
srichterthe trunk has not evolved as much in the mean time15:58
ignasthat was the idea15:58
th1aThat seems prudent.15:58
th1aOK.  Next big task:  pluggable UI.15:58
th1aWhat are your thoughts about this srichter?15:58
srichterUI: I did not have time yet to review the pagelet code in the trunk, but:15:59
srichterI looked at it briefly and the examples seem more complex than the simple use cases we need at first15:59
srichteranother advantage is that we will have Roger's support if we use this15:59
th1aIt seems like we will have to write in some time to make a final evaluation of the available options.16:00
srichtereven if we do not like what we see (implementation), we can improve it and Roger will be happy someone contributed16:00
algaI'm all for moving to what's the state of the art in z316:00
algaand not reinventing the wheel instead16:00
srichteralga: well, there is none16:00
th1aWell, I think state of the art is in some dispute.16:00
srichterthere is the z2ecm stuff, but I talked to ZC people and they say it will not fit our needs well16:01
th1aAny particular reason?16:01
srichterZC developed their own little system, but it does not cover our use cases either16:01
th1aSo it seems likely that pagelets are best?  We should start there?16:02
srichterth1a: the z3ecm stuff concentrates more on UI-based skin development16:02
srichterwhich is based on cpsskin, which might be far too heavy for us16:02
srichterth1a: I think so16:02
bskahanI agree about the z3ecm stuff not working for us16:02
srichterbskahan: have you looked at the pagelet code some more?16:03
bskahanit's targeted at building an entire UI, not plugging new peices into an existing one16:03
bskahansrichter: yes, I think it meets our needs or comes close enough to be the right place to start16:03
srichterI think we should (a) write down our use cases and (b) see that we write a very minimal example using
bskahanwe need pluggbable menus and regions16:04
* bskahan nods16:04
th1aUse cases from the component's point of view?16:04
srichter(b) will serve as documentation for others to use as well16:04
bskahanfrom the third party developer's point of view16:04
srichterth1a: yeah, basically, what do we want to achieve using pagelets in ST16:05
srichterwith concrete examples16:05
th1aOK.  We'll work on that in detail.  Let's move on for the moment.16:05
srichterand the benefits16:05
th1aSample data.16:05
th1aIt seems like we should be able to use interfaces to generate sample data for components.16:06
srichteroh yeah16:06
th1aTo help, at least.16:06
srichterI think we should borrow Jim's layer concepts from tests16:07
srichteryou fdefine layers of sample data16:07
th1aI'm getting closer to being able to use correct Z3 jargon...16:07
srichterthat might depend on each other16:07
srichterthen you can say, I want this and that layer16:07
srichterand packages subscribe to those layers to add content16:07
srichter(or can even create new layers)16:08
mgedminit looks like it might just work16:08
mgedminso, a layer would be an interface?16:08
mgedminregistered as an utility?16:09
th1aI was going to say "utility."16:09
bskahanand each new module would provide a layer (and define what other modules it depends on)?16:09
mgedminand you would register subscribers for (IGenerateSampleDataEvent, some_layer)?16:09
srichtermgedmin: something like that16:10
srichterWe just have to handle dependencies16:10
srichtermaybe a layer should be a component16:10
mgedminis there something in Z3 for dependency handling?16:10
th1aWhat is dependent on what?16:10
mgedminI remember there used to be some tools for handling dependencies among local components16:10
srichterthat keeps track of: the layer interface, dependencies, generate methof16:10
mgedminth1a, one layer ("sample calendars") might depend on another layer ("sample persons")16:11
srichtermgedmin: right, there is dependency code, but I do not know whether it is suitable here16:11
th1aBut calendars are dependent on persons anyhow.16:11
algain the implementation of "sample calendars" call "sample persons", and live with it?16:12
th1aAt this point, that seems adequate.16:12
mgedminI'd be happier if we went from requirements and user interface mockups to implementation details rather than starting with implementation details16:12
th1aWe are not, for the next year at least, literally worried about what happens when people remove core pieces of SchoolTool and try to run it.16:12
srichteralga: well, but you might get duplication errors16:13
srichterunless you want to be able to only generate one layer at a time16:13
mgedminso, does a user choose what bits of data he wants?16:13
mgedminwhen the user generates sample data, what happens to existing data?16:13
th1aYes, although it doesn't have to be fine grained.16:13
mgedminis it replaced or supplemented?16:13
th1aThis is a development tool.16:14
th1aWhat would be more useful to you as a developer?16:14
srichtermgedmin: Could we assume the DB is empty?16:14
srichterI think we should :-)16:14
srichter(for now)16:14
mgedminwe can't assume16:14
mgedminwhat do we do when it's not empty?16:14
srichtergo until you find a conflict and break16:15
th1aI'd say add the sample data.16:15
mgedminchoices: refuse to generate data, clear DB and generate data, do not clear DB and generate data16:15
algaignore duplicates?16:15
th1aDon't clear the DB.16:15
srichterI agree with Tom that this is a developer tool and does not have to be end user savvy16:15
bskahan"new sample" and "more sample" would be nice16:15
mgedmin"clear all data" might come in useful too16:15
alga"clear all fake data"16:15
mgedminif we have enough confirmation dialogs to make it hard to accidentally lose data16:15
srichterclear all data == remove Data.fs16:15
mgedmin"clear all fake data" is a bit harder... marker interfaces?16:15
th1aThis could be restricted to developer mode.16:16
mgedminok, back to ui16:16
srichtermgedmin: I think you are thinking about it too hard16:16
mgedminso the developer goes to some special developer mode page16:16
mgedminsrichter, so do I :)16:16
mgedminso the developer goes to some special developer mode page16:16
mgedminfinds "sample data"16:16
mgedminthen checks a few checkboxes?16:16
srichterthe point is not to create a end-user capable tool but allow us to put in data wuickly16:16
mgedmin[x] calendars, [x] timetables16:16
mgedminschool size: small|medium|large16:17
mgedminwhy do we need checkboxes/layers?16:17
mgedminwhy not generate everything that is possible?16:17
th1aSave time?16:17
srichtermgedmin: I thought it was one of your requirement to be able to do this incremental and partial?16:18
srichterI think genreate everything is perfectly fine with me16:18
th1aSounds ok by me.16:18
srichter(until I hit a use case when it sucks :-)16:18
th1aMy use case is that I just want to be able to review the latest code with real-looking data easily.16:18
mgedminsrichter, I think the "incremental" and "partial" bits were not for the user, but for the developer16:19
srichterright, I know16:19
th1aAnd I want new components to have new data as they are being developed.16:19
mgedminif I write an ST addon that adds, say, lottery tickets on persons, I want to be able to plug into the sample data generator16:19
srichterI just don't have use cases for now, so its hard to see what we want16:19
mgedminI thought a few subscribers might be enough16:20
mgedmingenerate sample data for the school16:20
mgedminthen for each person/group/resource we fire "generate sample data for this person/..."16:20
th1aAgain, these are mostly third party developer use cases, so we all just have to imagine we're third party developers.  Another target user is the school admin who wants to kick SchoolTool's tires easily.16:20
srichternote that subscribers do not have an order, so be very careful here16:20
mgedminthat's why I envisioned an event for every object, so that you only attach things to objects that were already generated16:21
mgedmininstead of traversing and relying on other generators to have created something first16:21
srichterthe more I think about it, the more I like your idea of a marker interface16:21
th1aOK.  Let's not go deeper into it at this point.16:22
th1aMoving on...16:22
srichterbecause then we can listen to ObjectAddedEvent and renotify it has (IObjectAddedEvent, IContentComponent, ISampleData)16:22
srichterand then write subscribers for that16:22
th1aCSV import/export needs to be handled more systematically.16:23
th1aAgain, it feels to me like we should be able to manage CSV import using interfaces.16:23
th1aBased on schemas.16:23
mgedminsome of it -- yes16:23
algado you insist on CSV?16:23
th1aIn the real world, yes.16:24
algawould the RESTive format dumps be too hard for the user?16:24
mgedminalga, yes16:24
srichteryes, definitely16:24
th1aSadly, yes.16:24
algacan we transform CSV into REST?16:24
mgedminwhy would we want to?16:24
srichterI think CSV would not provide a full mapping of the data16:25
th1aTo feel like the investment in REST is justified...16:25
algaREST is THE serialization16:25
th1aRealistically, schools will be dumping data out of spreadsheets and Excel.16:25
algaCSV is a nice wrapper for the users16:25
* srichter will eventually start a discussion on the justification of REST (I still cannot see it)16:25
th1asrichter:  Sorry I brought it up...16:26
srichterthe problem with REST is that there are no high-level editors16:26
mgedminthe reason for REST is that you can write one16:26
srichterhaving a school admin edit XML is nto an option (and not good for the integrety of the system)16:26
th1aDoes it seem practical to make the CSV *importing* more automatic and based off interfaces?16:27
mgedminalga, re mapping CSV -> REST: one line of CSV is likely to result in several RESTive requests16:27
bskahanexcel is pretty much the target client application until someone writes a REST client16:27
srichtermgedmin: right, but this use case is very utopian16:27
ignassrichter, REST is the answer for people that ask - how can i integrate my java thigajamajig with SchoolTool16:27
mgedminwhy do it in client side?16:27
th1aLet's NOT discuss REST.16:27
* srichter stops16:27
mgedminscope of CSV?16:27
mgedminwhat is it?16:27
srichterI think we need use cases16:27
srichterone would be the easy upload of users16:28
srichtereasy upload of grades16:28
th1aWell, right now we run into cases where we've done CSV import for objects that only cover some attributes.16:28
srichter(I love that blackboard feature)16:28
th1aAnd pretty quickly we get into "I want to import this other attribute in my CSV."16:28
th1aSo should we just let all attributes in an object's schema be imported via CSV?16:29
srichterth1a: it should be very hard (if not impossible) for CSV to mess with the system's integrety, so mapping only "safe" attributes is a good choice16:29
mgedminth1a, what is "object" here?16:29
srichterobject: Person, Group, Resource, ...16:29
mgedminare we talking just about top-level objects (those stored in top-level containers)?16:29
srichtermgedmin: I would hope so, if not we open a huge can of worms16:29
mgedminif we go into importing calendar events etc., things get difficult -- so would that be in scope?16:30
th1aCalendar events, no.16:30
mgedminalso, for example, some Person attributes are provided via adapters & annotations16:30
mgedminI imagine we want to import those16:30
srichterth1a: so maybe we can come up with a compoennt way of doing CSV16:30
srichterusing subscribers, similar to the new traverser code16:30
srichteryou register things that can be exported for a component16:31
srichterthe user then selects the attributes s/he wants in the export16:31
mgedminI think I like that...16:31
mgedminI envision something like this:16:31
srichter(this is similar to what blackboard allows you to do for student data, but more flexible)16:31
mgedminyou choose what you want to export (persons/groups/resources/etc)16:32
mgedminthen you get a set of attributes that you can export16:32
mgedminand you list those (e.g. "id,name,phone,list_of_groups")16:32
mgedminnames could refer to schema fields of the object, or to schema fields of adapters applied to the object16:33
mgedminwe could have some adapters used solely for import/export -- list_of_groups would be one example16:33
th1aImport and export have somewhat different requirements.16:33
srichterslightly OT: I think this brings up a whole new scope to SchoolTool: Application customization on a high-level16:33
th1aFor importing we can define fairly simple little csv documents.16:34
th1aFor exporting, we need to allow admins to configure big complex dumps according to their specific requirements.16:34
th1aActually, we should probably not do exporting now.16:34
th1aAt least the complex cases.16:34
mgedminfrom my point of view it seems that export is easier than import16:35
srichterI think the simple format should be a special case of the complex one16:35
ignaswhat is a complex format ?16:35
srichterbasically, for dummy users we do not give them all the power16:35
ignaswhat is the most complex case we can get in ST at the moment ?16:36
srichterignas: I would think the very generic mechanism Marius described is complex16:36
srichterignas: simple would be: Export a grade list of this section16:36
th1aLike, send us all the demographic data for all the student in your school in this exact pattern.16:36
srichterth1a: is this a *real* use case?16:37
mgedminsounds simple16:37
srichterth1a: this will almost always require some coding16:37
th1aNo child left behind, baby.16:37
ignasso one interface is not wenough i guess ... because some of these things can be stored deeper into an object ...16:37
srichterwe will just have to ensure that our framework is flexible enough to handle those cases16:37
ignaslike an attribute of an attribute ...16:37
th1aI haven't really looked at these things in detail, but they are the bane of school admin's existence apparently.16:37
mgedminI hate starting from vague specs16:38
th1aIt is just that you have to have an interface or templating language that gets the format just right.16:38
ignasth1a, maybe you could get a few real requests that admins are getting ?16:38
srichterok, I would not worry about supporting an X complex system, but rather ensure that someone can do it in third party code16:38
ignasso we could use them as a base requirements ...16:38
th1aI think my point is that we don't want to deal with those cases at this point anyhow.16:38
th1aTrying to get back on track.16:39
srichterok, to sum up: I like Marius' approach to complex cases and if done with the CA it should be flexible enough for all later use cases16:39
th1aLet's just assume that we aren't dealing with the question of difficult formatting.16:39
mgedminwhat's difficult formatting?16:39
mgedminwe're talking CSV here16:40
mgedminone line per object, comma separated strings16:40
srichtermgedmin: for example, if you get a list of groups a student belongs to, how is  this list formatted (in a single cell)16:40
mgedminunless you think we might have a field that is composed from several attributes?16:40
srichterdo you provide the id, title, both...?16:40
mgedmine.g. address "$street $number, $city, $whatever"?16:40
mgedminsrichter, we do this now -- we use space separated list of IDs16:41
mgedminit breaks down when you have spaces in your IDs, obviously16:41
srichtermgedmin: but this might not be the requirement for a particular district16:41
mgedminthat's why I imagine the admin will want to specify the format himself16:41
mgedminand by "specify the format", the simplest thing that I can imagine is16:41
mgedmina single line of comma separated field names16:42
srichterso anyways, if we do all this with adapters/subscribers we are safe, because admins can register custom subscribers16:42
mgedminimport format: "id, title, foo, bar, baz"16:42
algasrichter: in theory :-)16:42
mgedminwhere we list all available fields somewhere on the page16:42
mgedminif you have some very complex requirements, you can write an add-in16:42
mgedminwith custom CSV import/export views16:42
th1aHere's what the UK requires when you transfer a student from one school to another:
algaare we trying to support moving students with CSV?16:45
srichterth1a: is CSV import/export such a high priority now? We do not even have a functioning SIS system ;-)16:46
srichtershould we not concentrate on getting the data structures into palce first?16:46
th1aWell, I keep trying to say that import is more of an issue than export.16:47
th1aIn the immediate term.16:47
mgedminAFAIU somewhat customizable CSV import/export is a requirement for the April release16:47
th1aBut it is a fair question.16:47
mgedminthe exact scope is murky, <whine>as always</whine>16:47
th1aWell, here's the question, then.16:48
th1aIs there a reason to make this a framework level issue,16:48
th1aor continue to have it be handled ad hoc by each add-on package?16:48
algaI have a feeling that you're in the best position to answer this16:49
mgedminI feel that some framework support is needed16:49
srichterright, me too16:49
mgedmindemographics is a plugin, and I assume we want to import demographics at the same time when we import pupils16:50
srichterwe should develop an initial framework and extend it as necessary16:50
mgedminso one CSV for both core data and add-on data16:50
algathat's a point16:50
mgedminpossibly it is as simple as defining some field names and tying them to an interface/attribute name pair for adaptation and assignment16:50
th1aI wouldn't say having one combined CSV is a requirement.16:51
th1aBasically, when you add a demographics schema, it should be pretty straightforward to make it also importable via CSV.16:51
th1aIf it requires a separate file at this point, that's ok.16:51
th1aAnyhow... I think we've beaten this to death, at least as long as we're typing.16:52
th1aBuilt-in roles.16:52
th1aWe need some.16:52
mgedminwhat's that?16:52
th1aMore or less.16:53
th1aI don't think there's anything tricky about it.16:53
th1aBut people with fundamentally different roles are going to need to start getting different views.16:53
srichterso here is the tricky question?16:54
srichterShould we implement different roles or different groups?16:54
th1aI guess that is the question.16:54
srichterboth, roles and groups, are collections, so we can choose either one16:54
srichterI would prefer groups16:55
srichterbecause then I can annotate data to it16:55
srichterlike the workflow stuff I did16:55
th1aThis overlaps with my last little point on my draft about access control based on relationships.16:55
algagroups in ST sense?16:55
alganot the Z3 security policy?16:55
th1aHow do we designate that a parent, for example, can see only their child's personal info?16:56
th1aLocal role?16:56
th1aOr actually derived from relationships?16:56
srichterlocal role16:56
mgedminI saw steve alexander's presentation about the security model they use in launchpad16:57
srichteralga: I was talking about the Group class, which is efectively a Z3 security policy component16:57
mgedminthey use adapters that can grant or deny access according to object type16:57
ignasmgedmin, +116:57
algathat's basically defining our own security policy16:57
mgedminignas, ditching the standard z3 security policy and rolling our own is a big step16:58
mgedminmaybe it would be good, maybe not, I am not sure16:58
mgedminnow the security is almost completely in the hands of the user16:58
algaWe need to have a solid understanding what are the requirements for the security machinery16:58
mgedminwhich is flexible, but overwhelming, unintuitive, complex, and probably not very secure16:58
ignasif we want permissions that depend on 2-3 step relationships it might be the most sensible way ...16:58
algaseeing your child's data is just one example16:58
srichterI would be hesitant about implementing our own security policy16:59
algath1a: do you imagine what are the security/permission models you'd like to see?16:59
srichterjust because it is a lot of code to support16:59
ignaslike - janitor can see when a resource is not busy if the resource is a location ...17:00
th1aWe should probably talk about security offline for a while.17:00
th1aSo... wrapping up for a bit, I would point out that one outcome of this discussion may be to drop some of these things that we can't actually clearly define at this point.17:01
mgedminsrichter, it's not that much code17:01
th1aWhich is an OK outcome!17:01
mgedminthe question is, which security policy matches our requirements better17:01
mgedminand I'm unqualified to answer it, since I do not understand what our security requirements are :(17:01
srichterI think we should change the dev model a bit17:02
srichterwe should start developing the data model we need17:02
srichterin the mean time Tom can contact schools and collect real use cases17:02
srichterand then we start working at one requirement at a time17:03
srichterwe are doing a lot of guessing on what's needed17:03
srichterfor example, I could provide in good deal the requirements from a teacher's and student's perspective in a small university, simply because I am filling both roles at the moment17:04
ignasor maybe reduce the size of iterations ?17:04
srichterignas: what do you mean?17:04
ignasbecause well the scope of the proposal is 1 month17:04
srichteroh, I see what you are saying17:05
ignaswhich with productive enough programmers becomes way to large to estimate without guesswork17:05
ignaswithout an accurate proposal - we can't divide up the work/ find out what features to cut and etc.17:05
*** tiredbones has joined #schooltool18:17
srichterdid you guys know that you recuurence objects are not persistent?18:19
mgedmina long time ago recurrence objects were immutable data values, sort of like strings or datetimes18:20
mgedminnow they aren't, but in any case, they're not supposed to ever be shared between more than one object18:21
srichteras long as they can change, don't they have to be persistent?18:22
mgedminI knew there was at least one more reason I felt uneasy about making them mutable18:23
mgedminpersistency pinging18:23
mgedminI'm sure that's not a problem right now, but it could easily become one18:23
* srichter has to put so much BBB code into this clean ST code :-/18:27
srichterBBB is a shortcut for backward-compatibility18:28
srichtereventually we have to support generic object path aliases18:28
srichterI am going to chat with Tim next week to imlement some support in the ZODB18:28
srichterthe hardest part will be to write the evolution script for relationships18:31
srichterother than that I seem to have everything under control18:40
srichterth1a: btw, I am interested int he outcome of the discussion you had18:57
th1aWell, we decided that some kind of relationship-based access control was going to have to be devised, but decided we'd have to let that ferment for a little while before we'd be able to draft a proposal.18:58
th1aI had been hoping to spend more time talking about that two weeks ago but we hadn't gotten to it.18:59
th1aI'm starting to write up some pluggable UI use cases.\18:59
th1aThat's going to be the main part of the proposal.18:59
th1aI think we're going to defer import/export until we do the personal info/demographics stuff, because they make sense together.19:00
th1aBTW... I'm trying to focus on things that don't really require detailed end user use cases.19:01
th1aI want to focus on developer issues.19:02
th1aBut it is looking like we'll just defer some of them until they're embedded in more specific end-user functionality.19:02
th1aAnyway... I should shut up and write use cases.19:05
th1aI think that's the consensus :-)19:05
th1abskahan:  ayt?19:38
bskahanth1a: was away from the keyboard for a bit20:02
th1aI think I've figured out how I have to can write the pluggability use cases usefully.20:03
bskahanwhat are you thinking?20:04
th1aBasically go over the main components that we have to create and roughly what needs to be plugged for that component for the main view of each built in group (teacher, student, clerk, administrator)20:04
th1aAnd for each application object when viewed directly.20:05
th1aWe sort of have a dichotomy between having user dashboards and viewing the objects directly.20:05
bskahanisn't that more of an "adaptable" UI (which I agree we need), vs. a "pluggable" UI (which we also need)20:06
bskahanby adaptable I mean, it sounds like your talking about changing what the user sees based on the users role and possibly context20:06
th1aI think, for example, that it is good that you would be able to navigate to a class and view the assignments for the class, but teachers will actually create those assignments from their main gradebook view.20:06
bskahanvs. pluggable, meaning a third party dev can create a new object on a person and get it added to the menu and rendered sanely in part of a page20:07
th1aWell, I'm bumping up against the realities.20:07
bskahani think we need both, but I'm not sure they need to be concurrent20:08
th1aWhat is forming in my mind is that you'll have an adaptable and pluggable dashboard, and some direct views of objects which are just pluggable.20:08
* bskahan nods20:09
bskahanI'd like to replace the default login redirect with that sort of dashboard (in place of the current calendar redirect)20:09
povbot/svn/commits: * srichter committed revision 4855:20:10
srichteryeah, that's what BlackBoard does20:10
povbot/svn/commits: Add initial cut of backward-compatibility code. We might notice more stuff later, but my fairly comprehensive set of data passed just fine.20:10
srichterBB has a fairly nice overview view20:10
bskahanwhat would be in the dashboard, as of today?20:10
srichterupcoming events20:10
bskahan(the reason I haven't pushed for it yet is that I think only upcoming events would be there now)20:10
th1aI guess the only real option in play is the possibility of deprecating navigating directly to objects almost entirely, which I don't think it is something we'd want to do.20:11
bskahanth1a: I think we definitely want to do that20:11
th1aWe do want to deprecate it?20:11
th1aI don't have strong feelings I guess.20:12
bskahanyes, we want the UI to focus on tasks to be accomplished, not "thing to do tasks on"20:12
srichtermmh, I start to think that deprecation might be ok for high-level users20:12
srichterthe only people that think in terms of objects, are managers20:12
srichterlike: I want to delete this person20:13
bskahansrichter: right20:13
th1aWell, I think that in most cases you would at most want to have a sort of read only view when you're viewing an object directly.20:13
th1aFor example, follow a link to a kid, and you get sort of a dashboard for the kid.20:13
bskahanI think in the long term, things liks the current PersonView are of limited value20:14
srichterbtw, when I played with ST yesterday I was very impressed with the Timetable Schema wizard and edit screens; we need more of those power views :-)20:14
th1aOr, on kid's page you can click "gradebook" to see grades, "info" to see info, etc.20:14
bskahanright, unless the PersonView pulls in the grades, schedules, notes, etc20:14
bskahanwe just don't have alot of those features yet20:14
srichterI wonder whether we should be so location centric20:15
th1aWell, I'm assuming that would be the case.20:15
srichtermaybe we should more write views for the principal in the request20:15
srichterI wonder whether we can bend Zope 3 to do this20:15
th1aWell, we've already steadily downplayed navigation/location.20:15
* bskahan nods20:15
mgedminhow is that different from writing views for ISTApplication and using request.principal inside?20:16
srichtermgedmin: the form of the request.principal defines the view20:16
srichterit was a stupid idea20:17
mgedminhmm... the login page can redirect to an appropriate view depending on the principal20:17
mgedminor the start page20:17
mgedmin(I mean @@index.html for ISTApp)20:18
srichtermaybe that's the way to approach all of this20:18
srichtertake a user and ask: what are those user's common tasks20:18
bskahanor, everyone redirects to a 'dashboard' of sorts, and the dashboard is populated with useful components based on the principal20:18
srichterbskahan: yeah, that's what blackboard does and it works ok20:19
th1aActually, I don't really want to do a dashboard yet.20:19
th1aEven by April we won't have enough components to make it necessary.20:19
* bskahan agrees20:19
th1aOr if we do that, it will be one of the last things.20:19
srichterI am also thinking that we spread ourselves thin here; currently we are working on a SIS and a course management system20:19
bskahanit should be a last thing20:19
bskahanso that its designed knowing what we can put in it ;)20:20
th1aMore accurately, we're doing and SIS and a gradebook.20:20
srichterok, in that case we can keep the assignments very minimal objects20:20
th1aWhen I say "creating an assignment" I just mean some metadata.20:20
srichterit is just an entry in the gradebook20:20
th1aTrig quiz, 10 points, September 12, etc.20:21
bskahanand it should create an event in the calendar20:21
bskahanor something event-like20:21
srichterRight, I think we should not worry about the description of the assignment though20:21
th1aRight, so the calendar will be dashboardy.20:21
th1aWell, a description textbox is easy enough.20:21
th1aJust like an event description.20:22
bskahanis the assignment an event-like object (located under a calendar URL) or is it an object located under a Section that is related to a calendar event?20:23
srichterth1a: OT: it would be nice if you could use .txt suffixes for your proposals :-)20:23
th1aSorry.  Mac habits.20:23
th1aActually, I think I assume it appends it, but it is invisible anyhow, so I don't know.20:24
th1abskahan:  I'd imagine the latter.20:27
bskahanth1a: that's what I thought, just checking20:28
bskahanI'm grabbing lunch, back in 20 minutes or so20:40
th1aOK.  I think I will have something useful by tomorrow morning.20:41
*** th1a has quit IRC20:43
povbot/svn/commits: * srichter committed revision 4856:21:57
povbot/svn/commits: Remove in anticipation of merge.21:57
srichterI see that the Zope 3 external is gone from the repository; how are we supposed to get SchoolTool running?22:01
srichterok, I see22:01
srichternever mind22:02
mgedmin'make run' ;)22:10
bskahanapt-get install zope-libs ;)22:23
*** tvon has joined #schooltool22:25
*** ignas has quit IRC22:32
srichtermgedmin: I am making progress with the merging... sigh23:24
*** bskahan has quit IRC23:29
povbot/svn/commits: * srichter committed revision 4857:23:52
povbot/svn/commits: Started merging the trunk checkins of schoolbell and schooltool to the branch:23:52
povbot/svn/commits: Merged: 4611, 4616, 4621, 4633, 4640, 4650, 4652, 4653, 4654, 4655, 4659,23:52
povbot/svn/commits: 4660, 4664, 4674, 4678, 4679, 4680, 4682, 4683, 4684, 4685, 4686, 4687, 4688, 4689, 4690, 4693, 4694, 4695, 4696, 4697, 4698, 4699, 4700, 4701, 4702,23:52
povbot/svn/commits: Ignored: 4613, 4625, 4626, 4629, 4630, 4631, 4638, 4651, 4673, 4681, 4692,23:52
povbot/svn/commits: * srichter committed revision 4858:23:55
povbot/svn/commits: Remove to replace with new version23:55
*** alga has quit IRC23:56
*** mgedmin has quit IRC23:56

Generated by 2.15.1 by Marius Gedminas - find it at!