Fixed, sorry.

Scott

Anthony Perritano wrote:
> i updated all my projects and i get the following build error:
>
>
> The method getContainingPodId() is undefined for the type  
> Rim<capture#1-of ?>   sail-data-emf/src/main/java/net/sf/sail/emf/launch      
>  
> EMFBundleAnnotationService.java       line 85 1208371192208   559673
>
> -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
-~----------~----~----~----~------~----~------~--~---

Reply via email to