The new methods in PasCurnitsUtils are based on using the bean and the pod functionality is handled underneath.right? but in the case of an activity/step move. a step could be removed from one list and placed in another. those activities steps lists would be updated.
i am confused on how the new structure would be created. would i remove the old activity? add the new one that has the updated steplist? the scenarios we have are: reorder activities reorder steps in the activity move a step to a different activity than its own. what combinations of remove and step are used for these with the new curnit structure? are we just updating activity and steplists? -Tony On 7/24/07, Turadg <[EMAIL PROTECTED]> wrote: > > > Excellent points Scott. I'm not much in the loop anymore and was > soliciting such issues in my proposal e-mail last week. I got one > affirmative reply and a few days of silence, which I thought was > consent. But as I think about it, I sent it Thursday evening so that > basically worked out to just one whole workday, Friday. > > This probably kills the "one pod for Pas" idea. It's a big trade-off. > > I ran into the rim name collision issue and got around it by prefixing > the old rim name with the epoch seconds at its creation. A drawback > to this is that the rim name changes with each build. On further > thought, I suppose that's completely unworkable. > > Finding the context of a rim could be helped with some step to rim > map. The problem is that steps don't have identifiers in this new > scheme. Pod ids were to be step's identifiers. But steps could have > identifiers if we wanted. Consider the smaller case of wanting to put > a whole activity in one pod. Should we allow this? In that case > there would have to be some step naming (for software, not display > like the title) to keep them unique and persistent within the one > activity pod. > > Same scheme could be used for the logging. > > Of course, this "one pod" simplification then isn't so simple. I made > the change to make it easier for Tony to develop the authoring tool > within hitting snags in working with pods. Given the learner data > issues you point out, I think the trade-off isn't worth it. So please > go ahead and flip that boolean in the WISE Project Converter. I'd do > it myself except I'm not at my dev machine right now and it would be > good for someone else to see that code. > > Hopefully the methods in PasCurnitUtils will be enough to shield the > authoring tool from pod matters. > > Scott, can you also write back to the Replacing XMLEncoder thread? > Maybe we can improve pods sooner than later. > > -Turadg > > > > On Jul 23, 8:58 pm, Scott Cytacki <[EMAIL PROTECTED]> wrote: > > How does this deal with the user data. > > > > It used to be keyed off of pod id and rim name. If there is only one > > pod, then that means the rim names have to be unique across the whole > > curnit. > > > > Many of the rim names in the old curnit format (one pod per step), were > > "undefined1", "undefined2". At least because they were inside of pods > > we could identify the context of the rim by finding the pod and doing > > our best to parse the xmlencoder for that pod. > > > > If there is one pod, then I assume that means there will be one giant > > xmlencoder file that contains all the steps. It will be pretty > > difficult to parse this to figure out the context of a rim. > > > > Additionally the navigation log was based on the pod id. So with one > > pod, the navigation log will no longer be meaningful. Having multiple > > pods was a nice abstraction from the specific implementation of pas, > > onto which tools like the reporting parts of the sds could be built. > > > > I agree that the way it was working with multiple pods, and xmlencoder > > was not good. But replacing that with a single giant xmlencoder file > > will make the situation worse from the student data point of view. > > > > ScottTuradg wrote: > > > Ok, I've gone ahead with the > plan. Seehttp://www.telscenter.org/jira/browse/PAS-508 > > > andhttp://fisheye3.cenqua.com/changelog/tels/?cs=2136. > > > > > So now curnits spit out by the converter have just ONE pod. All the > > > beans go in there. When we figure out a workable system for reuse, we > > > can add it in then. > > > > > The ProjectConverter has a boolean flag for whether to *share* the pod > > > among all the beans or let them each have their own. Right now it's > > > settable only in code, since we should be careful about switching that > > > flag. > > > > > I made the PasCurnitUtils so it can tell the difference between > > > sharing pods and individual pods, but I haven't been able to test it > > > thoroughly. Tony, I hope you can add more tests to > > > PasCurnitUtilsTest. Good work on making that. > > > > > I'll write in the other thread on the move methods. > > > > > On Jul 19, 6:40 pm, "Anthony Perritano" <[EMAIL PROTECTED]> wrote: > > > > >> right on. i think it will make it easier to built better tools, debug > pod > > >> serialization problems..etc yes our original reuse plan kinda fades > away. > > >> but maybe we should think about reuse on the bean level, if such a > thing can > > >> be done. > > > > >> -Tony > > > > >> On 7/19/07, Turadg <[EMAIL PROTECTED]> wrote: > > > > >>> Tony and other Pas developers, please take a look at this proposal > and > > >>> let me know what you think. Particularly, what are your concerns? > > >>> I'll try to address them. > > > > >>> > http://www.telscenter.org/confluence/display/PAS/Proposal+for+one+pod... > > > > >>> -t > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
