I've got this basically working now. There is a launcher: PasOTrunkHelloWorldTest which runs a OTrunkCurnit which has a single hello world step. When it starts up there is a file open dialog which allows you to specify some user data file. If you cancel this dialog it will start fresh. When it exits a file save dialog shows up that allows you to save the user data file.
So to test the round trip of user data do the following: - run it and hit cancel on the first dialog - enter some info in the hello world step - quit the application - choose a file to save the user data into. - run it again and choose the same file you saved into. - verify the info you entered in shows up again You'll need to update at least: sail-core sail-data-emf sail-otrunk pas-otrunk otrunk If you look at the OTHelloWorldController you can see how it is creating an OTrunkRim and setting that on the HelloWorld step. The otml file it is using is: pas-otrunk/src/test/resources/pas-helloworld-test.otml Next steps: -- Need a way to force OTObjects to have UUIDs -- Notice how the OTHelloWorld element now has an id attribute: <OTHelloWorld ... id="9FF253B1-3C3F-4CD9-ADAB-0AB60CDE3427"/> That is required for the userdata saving to work. I need come up with a way for you to make sure those ids are assigned when you create objects in the AuthoringTool or the converter. A relative id system is used by default instead of the UUID one. -- All Generic OTrunkSteps save their data in a single rim -- I'm not sure if that is good or bad. It is the direction we want to head, but it might disrupt some of the work Aaron has been doing recently. -- Tony or Geoff try to use this approach for QTI steps -- Scott Scott Cytacki wrote: > After looking at the Pas Step code a bit, it seems like we can continue > to use the emf data persistence for OTrunkCurnits. > > In the non-QTI case the controllers can create Rim objects and set them > on the step bean. Then the step bean can use that rim to look up a sock. > > The Rim object will need to be updated so its method > public PodUuid getContainingPodId() > is replaced with > public UUID getContainerId() > Then in the OTrunkCurnit case this will return the UUID of the OTrunk > object representing the step. > > In the QTI case the Rim objects could be created by the controller or > maybe it is better to create them in the step bean itself. But in > either case the names of the rims will be the responsedeclaration > identifier. > > In both the QTI and non-QTI case the Rims can be created at learner > runtime instead of authortime. As long as their name (which is their id > within their container), can be determined from the authored content. I > think in most cases we can keep the same Rim names used by the current > TELS projects. This way the reporting code won't need to be changed. > > Most of this work will be reusable when OTrunk is used for the learner > data persistence. Most likely none of the steps beans or controllers > will need to be changed. There will just need to be a UserDataService > (actually called AgentService) implementation to replace the emf one. > And some new properties and OTClasses added to the existing Pas OTClasses. > > I'll get started making this work with the HelloWorld step. > > Scott > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
