Another scenario which is even more likely to occur in classroom settings. Suppose I run a week long project. It has six activities. My sample class has 27 students. All students pair up and one students works by herself. Students A & B are paired. Student C is the solo. On day three of the project, student A gets strep throat and will be out of school for two weeks (you¹d be amazed how often this sort of thing happens). Students B & C ask if they can work together for the remainder of the project. They¹ve both already completed Activities 1 and 2, and want to do Activities 3-6 together. If I move student B into student C¹s team, do I replace all of her Activity 1 and 2 work with the existing work done by student C? If I move Student C into Student B¹s team, do we override Student C¹s established data.? If we keep track of their individual data, how is this melded once they¹re in a group?
My suggested compromise: - if student A is moved into a new group X and that student has any stored data, then the system warns the teacher that the Student A¹s existing data file will be updated to match the work already completed by the Group X, and all previous work completed by the student will be appended as ³Archived Work.² So now student A is unified with the other student(s) in team X, except that Student A¹s also include their old work (marked with a header tag along the lines of ³ARCHIVED WORK before transfer to new group on [date]. ³ This should be fairly easy to due for the text in Notes, but we¹d have to decide how to handle the many other types of assessment steps. Let¹s discuss next week, MattFish From: Hiroki <[EMAIL PROTECTED]> Reply-To: <[email protected]> Date: Thu, 24 May 2007 17:26:35 -0000 To: SAIL-Dev <[email protected]> Subject: [SAIL-Dev] Re: sds workgroup memberships One more thing that I would like to throw in this discussion is "What happens when students change workgroups? How are their saved-data associated to them?" For example, consider this sequence of action: A,B,C are students 1) A&B work together in workgroup 1, C works in workgroup 2 2) A moves to workgroup 2, works with C; B works in workgroup 1 3) A moves back to workgroup 1, works with B; C works in workgroup 2. If I remember correctly from our discussion in last year's retreat, all of the data gets stored, along with the workgroup membership? If so, how can the portal access this information? For example, how can the portal access all of the work that Student A did? Is there some kind of documentation for the above scenario? This might be something we can discuss next Wednesday at the SAIL meeting? Hiroki On May 24, 9:58 am, laurel <[EMAIL PROTECTED]> wrote: > Just so you know what I'm working on and why all the questions, I'm > working on the portal code to update workgroups and by extension > workgroup memberships. > > I am finding that on the SDS now I can go to the web interface and > remove all users from a workgroup. This does not cause any failures. > > While the use cases are questionable, I'm just feeling uncomfortable > with the change in the way things work for a boundary case. If I can > update a workgroup to a brand new set of users, why doesn't updating > with <workgroup-members></workgroup-members> remove all the users? > > That just seems wierd to me. > > Laurel > > On May 24, 11:05 am, Aaron <[EMAIL PROTECTED]> wrote: > > > Laurel- > > > The xml for an empty workgroup should now be fixed. (And apparently > > is... I love quick easy fixes.) > > > Technical details: > > The nil-class element was an artifact of the built-in ruby xml > > generator. Basically it was being passed an empty array, and since > > ruby isn't a typed language, it had no idea what type of objects the > > array was supposed to hold, hence the nil-class. When there's at > > least 1 object in the array, it can figure it out based on that > > object's class type. I provided an override for the empty set, so > > that it still puts the expected xml. > > > As far as removing all the users from a workgroup, what's the use > > case for this? I can see creating a temporarily empty workgroup, but > > then once it has members, why would you need to go back to being empty? > > > -- Aaron > > > On May 24, 2007, at 10:57 AM, laurel wrote: > > > > Wow...I wrote the test code for this and by the time I'd finished > > > writing it, it worked...talk about quick response. Laurel > > > > On May 24, 10:32 am, laurel <[EMAIL PROTECTED]> wrote: > > >> Thanks Aaron - I should have remembered that. > > > >> I have another question > > > >> 1) I create a workgroup, but have not yet created members for that > > >> workgroup. I can see this as a use case where a teacher decides to > > >> create 4 workgroups for his/her class but leaves the assignments to > > >> the students or just puts it off until later. > > > >> 2) I do a query to find out the members of the workgroup (there are > > >> none) and get the response below > > > >> curl -i -X GET -H 'Accept: application/xml'http:// > > >> rails.dev.concord.org/sds/4/workgroup/1403/membership > > >> HTTP/1.1 200 OK > > >> Date: Thu, 24 May 2007 14:25:23 GMT > > >> Server: lighttpd/1.4.11 > > >> Content-Type: application/xml > > >> Cache-Control: no-cache > > >> Content-Length: 68 > > > >> <?xml version="1.0" encoding="UTF-8"?> > > >> <nil-classes> > > >> </nil-classes> > > > >> I think it would be more useful to return the same response as a > > >> workgroup with members, but with an empty set of members...That way > > >> the same code could be used to parse the response. > > > >> i.e. > > > >> <workgroup-memberships> > > >> </workgroup-memberships> > > > >> Could that change be made? > > > >> Thanks, > > > >> Laurel > > > >> On May 23, 3:47 pm, Aaron <[EMAIL PROTECTED]> wrote: > > > >>> Hi Laurel- > > > >>> It turns out that a change made to the dev sds a while back was that > > >>> "users" are now "sail-users", and this apparently affects some of > > >>> the > > >>> REST API's. I will update this on the REST API confluence page (and > > >>> determine if any other API's are affected). > > > >>> So if you change the xml you're posting from: > > >>> <user-id>5362</user-id> > > >>> to: > > >>> <sail-user-id>5362</sail-user-id> > > > >>> it should work. > > > >>> Full xml: > > >>> <workgroup-memberships> > > >>> <workgroup-membership> > > >>> <sail-user-id>5362</sail-user-id> > > >>> </workgroup-membership> > > >>> </workgroup-memberships> > > > >>> -- Aaron > > > >>> -- > > >>> Aaron Unger > > >>> The Concord Consortium > > > >>> On May 23, 2007, at 2:45 PM, laurel wrote: > > > >>>> Hi all, > > > >>>> I'm doing the following on the SDS (using curl) and having problems > > >>>> and I'm wondering if anyone can help. Note that in step 2 I > > >>>> don't seem > > >>>> to get members in my workgroup, despite the fact that I've just > > >>>> created one. Can someone related to the SDS check out my > > >>>> technique and > > >>>> possibly suggest what I am doing wrong. Thx. > > > >>>> Laurel > > > >>>> 1) creating a membership list for a workgroup > > > >>>> curl -i -H 'Content-Type: application/xml' -X POST -d '<workgroup- > > >>>> memberships><workgroup-membership><user-id>5362</user-id></ > > >>>> workgroup- > > >>>> membership></workgroup-memberships>'http://rails.dev.concord.org/ > > >>>> sds/4/workgroup/1375/membership > > > >>>> HTTP/1.1 201 Created > > >>>> Date: Wed, 23 May 2007 18:22:01 GMT > > >>>> Server: lighttpd/1.4.11 > > >>>> Content-Type: application/xml > > >>>> Location:http://rails.dev.concord.org/sds/4/workgroup/1375/ > > >>>> membership > > >>>> Cache-Control: no-cache > > >>>> Content-Length: 0 > > > >>>> 2) retrieving a membership list for a workgroup > > > >>>> curl -i -X GET -H 'Accept: application/xml' > > >>>>http://rails.dev.concord.org/sds/4/workgroup/1375/membership > > > >>>> HTTP/1.1 200 OK > > >>>> Date: Wed, 23 May 2007 18:22:08 GMT > > >>>> Server: lighttpd/1.4.11 > > >>>> Content-Type: application/xml > > >>>> Cache-Control: no-cache > > >>>> Content-Length: 184 > > > >>>> <?xml version="1.0" encoding="UTF-8"?> > > >>>> <workgroup-memberships> > > >>>> <workgroup-membership> > > >>>> <sail-user-id nil="true"></sail-user-id> > > >>>> </workgroup-membership> > > >>>> </workgroup-memberships> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SAIL-Dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/SAIL-Dev?hl=en -~----------~----~----~----~------~----~------~--~---
