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 -~----------~----~----~----~------~----~------~--~---
