So i have been looking and stepping through the helloworld example
that uses rims for Pas-Otrunk based steps trying to figure out how to
apply that to Notes and QTI based steps.
scott you said:
>> 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.
>
Right now in QTI Based steps we have a bean property called:
Map<ResponseDeclarationType, Rim> responseDeclarationsToRims
The Note populates it self like this:
for (ResponseDeclarationType rd : responseDeclarations) {
//Rim rim = rd.getRim();
Rim rim = responseDeclarationsToRims.get(rd);
if (rim != null) {
try {
ISock<String> sock =
agentService.getSock(rim, agent);
responseDeclarationToSocks.put(rd, sock);
if (!sock.isEmpty()) {
//we have submitted
before
submitted= true;
responses.put(rd.getIdentifier(), sock.peek());
}// if
} catch (Exception e) {
logger.severe("exception: " +
e); //$NON-NLS-1$
}// try
}// if
}// for
All we need to do then is replicate the property
responseDeclarationsToRims on to the OTAssessmentController right?
which will save the map of responseDeclarationToRims to OTML. once
read in the LoadReadObject method that property will be set on the
real notebean. the above code should be able to be used. the
agentService should be available and able to look up the sock.
i would have to create the OTrunkRim similar to the HelloWorld style
correct?
-Tony
On Apr 15, 2008, at 5:30 PM, Scott Cytacki wrote:
>
> 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
-~----------~----~----~----~------~----~------~--~---
