I was hoping the persisted user data for pas would look the same as the persisted user data for udl, itsi, and capa. This way the reporting code could be unified.
So that would mean not using OTSock and OTSockEntry or OTPasInterfaceObject. It also means not storing the history of the sock entries. That would have to wait until the OTrunk logging is activated. So each Pas Step type that has rims would have properties on its OTClass to store the values. If the step type has multiple rims based on its content, then it would have a list of OTObjects representing that content and each would have a property to store the user data. OTAssessment is an example of that latter case, and QTI complicates this. I don't know if I have this right, so please correct me: Each OTAssessment has one qti AssessmentItem which has multiple qti BlockInteraction. Those BlockInteractions correspond to the tabs in the notes. When these BlockInteractions are created by the converter they have identifiers. Do they also have identifiers when they are created by the authoring tool? So I would add a OTObjectList property to OTAssessment which stores OTBlockInteraction objects. And then each OTBlockInteraction would have a property to store the identifier of the block interaction and a property to store the response. You might need to create sub OTClasses for the different types of BlockInteraction so you could store the responses correctly. So with these objects, then the particular PasStep would be loading and saving stuff directly into its own OTObject. If you want to keep PasSteps independent of OTrunk then you could stick an interface in between which the PasSteps use and the OTPas controllers implement. The draw back of this solution is the temporary loss of fine grained user data history. When I come back I plan to continue work on the logging code so this type of fine grain history is available to all OTrunk applications. I think this draw back is offset by the benefit from unifying the user data model for our multiple projects. Which ever approach is used, the reporting code in the SDS and Pas Portal is going to have to be updated to handle the new format of the user data. If the user data is unified then that work (which has to be done no mater what) will benefit more projects. And those projects will be working on improvements to the reporting, so Pas should benefit from that. Sticking with the rim, sock, and sockentry model will make updating the reporting code easier in the SDS and Pas Portal, but that work will only benefit Pas. Scott Aaron Unger wrote: > Tony, Geoff and I met today and discussed how to persist data from > PasSteps under pas-otrunk. Notes from the meeting can be found here: > http://www.telscenter.org/confluence/display/SAIL/Pas+OTrunk+Persistence+Model > > The page basically outlines a bunch of classes and interfaces that could > be used in order to allow pas steps to save into otrunk objects instead > of socks/sockentries, and hopefully will work for the situation Tony > describes below. > > Questions, comments, critiques are accepted. > -- Aaron > > Anthony Perritano wrote: > >> Aaron, geoff, hiroki and i had a good discussion about how to get PO- >> Trunk steps persisting learner data. The method that we want to >> explore is passing an OTrunk object into the pasStep and bypassing the >> rim/sock/pod model. After that discussion Hiroki, Geoff and I sat down >> and looked at our main scenario for persistence which is notes. i >> think one of the we are confused about is how our sock/rim model >> translates to this OTrunkTransferObject that is passed in. >> >> for instance, in our current model. there is a bean property on Notes >> that is a Map of ResponseDeclarationsToRims. this is created at author >> time. On start up of the step, that map is iterated and the rim is >> used to find its sock. once the sock is found or a new one is created >> it is put into a map ResponseDeclarationsToSocks. this is basically >> mapping the the question to the answer. >> >> i think the big question is this OTrunkPasTransferObject. How do we >> distinguish which data(a sock or OTrunk equivalent) goes with >> question. In our old model a 3 part note has 3 rims and 3 socks. are >> there OTrunk mechanisms that the transferObject can use? we are still >> going to need some mapping similar to ResponseDeclarationsToRims/ >> OTObject at author time? are there any examples that we can look at? >> >> thanks >> -Tony >> >> >> >> >> >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
