This page last changed on May 30, 2008 by scytacki.


Source code

Next steps

Setup a learner data test

  • setup an jackrabbit server that can be access over webdav
  • test the data saving into this server
  • setup a sds config that tells SailOTrunk to use this for the learner data
  • setup a test diy activity, and switch its config to be the one above

Import sds otml learner data

  • setup a test import to see how the references to the original objects are maintained
  • find a useful query or report that could be run on the imported data
  • make sure this query or report will work on the imported data
  • write a script or java program for doing the import

Repository representation improvements

Here a list of things that might need to be improved in the repository representation:

  • xml text is stored as escaped strings instead of nodes or binary blobs
  • there is no support for binary resources yet. In OTrunk these are url's or byte arrays.
  • OTrunk lists and maps have a verbose representation which will be hard to query.
  • the logic to navigate the structure is complex because an OTrunk property can be either a:
    • child node
    • reference property
    • string property which is a OTrunk id pointing to an object outside of the repository
  • consider making everything a reference and using a standard multi-valued "ot:child" node for the children. This won't handle external references.

Round tripping otml

It seems best if developers can continue to use otml to create and update content in the repository, this requires a few things:

  • the format of the original otml (whitespace, comments, local_ids) should be maintained so diffing works.
  • a merging tool will need to be created so developers can merge their otml into the repository.
  • otrunk objects that don't have ids will need to be matched with existing objects in the repository. Repository paths can be used for this.

Result of copying in an otml file

This example is helpful to see how the OTrunk objects are represented in the repository. The way they are represented is probably going to change because it needs to make querying the structure easy. The current represent was the quickest way to get something working.

If you look at the export from the repository you can see that the jcr:uuid attributes are used to reference objects in the repository. This allows the queries to take advantage of jackrabbit's built in reference handling.

Original file

the imports, and bundles have been removed to make it a little easier to read

<?xml version="1.0" encoding="UTF-8"?>
<otrunk id="33754150-b594-11d9-9669-0800200c9a66" >
        <OTCompoundDoc name="Compound Document">
            <table border="1">
                 <object refid="${graph}"/>
                 <object refid="${slider}"/>
            <!--  the graph which displays the value of the slider -->
            <OTDataCollector local_id="graph" name="Graph">
                <OTDataGraphable connectPoints="true" color="0x0000ff"
                  drawMarks="false" name="Slider Value" xColumn="0" yColumn="1">
                    <OTPropertyDataProducer timeScale="0.1"
                      target="${slider}" />
                <OTDataAxis min="0" max="100" label="Time" units="min"/>
                <OTDataAxis min="-10" max="10" label="sin(x)"/>
            <!--  the slider itself -->
            <OTSlider local_id="slider" name="Slider" minimum="-10" maximum="10" value="0"/>

Export of repository after these objects are copied in

The bundles have been removed to make it easier to read

  jcr:primaryType="nt:unstructured" jcr:uuid="77a984aa-73b3-426c-8e73-3dfcc1061039" ot:type="org.concord.otrunk.OTSystem">
  <bundles jcr:primaryType="nt:unstructured">
  <root jcr:primaryType="nt:unstructured" jcr:uuid="11f49c39-7c90-41af-b365-e952bfeb232f" 
    bodyText="&lt;table border=&quot;1&quot;&gt;&#13;&#10;
                 &lt;object refid=&quot;%94b07249-8fd1-40b3-8781-459abddbf429&quot; /&gt;&#13;&#10;
                 &lt;object refid=&quot;%42dcd2c6-1529-408d-bef3-46b16f2f26ba&quot; /&gt;&#13;&#10;
      name="Compound Document" ot:type="org.concord.otrunk.view.document.OTCompoundDoc">
    <children jcr:primaryType="nt:unstructured">
      <ot:item jcr:primaryType="nt:unstructured">
        <ot:value jcr:primaryType="nt:unstructured" jcr:uuid="94b07249-8fd1-40b3-8781-459abddbf429" 
           localId="graph" name="Graph" ot:type="org.concord.datagraph.state.OTDataCollector">
          <source jcr:primaryType="nt:unstructured" jcr:uuid="2b49d9c1-8b64-40b2-b646-57b52b233a76" 
             color="255" drawMarks="false" name="Slider Value" ot:type="org.concord.datagraph.state.OTDataGraphable">
            <dataProducer jcr:primaryType="nt:unstructured" jcr:uuid="96526b01-f1ce-42ae-b9e1-908f9e18f6cf" 
               property="value" target="42dcd2c6-1529-408d-bef3-46b16f2f26ba" timeScale="0.10000000149011612"/>
          <xDataAxis jcr:primaryType="nt:unstructured" jcr:uuid="38ea67b8-82df-4c20-a8aa-f1feb7d81f77" 
             label="Time" max="100.0" min="0.0" ot:type="org.concord.datagraph.state.OTDataAxis" units="min"/>
          <yDataAxis jcr:primaryType="nt:unstructured" jcr:uuid="70e09dbf-819e-4311-8154-ae4f63e8ada6" 
             label="sin(x)" max="10.0" min="-10.0" ot:type="org.concord.datagraph.state.OTDataAxis"/>
      <ot:item jcr:primaryType="nt:unstructured">
        <ot:value jcr:primaryType="nt:unstructured" jcr:uuid="42dcd2c6-1529-408d-bef3-46b16f2f26ba" 
            localId="slider" maximum="10" minimum="-10" name="Slider" ot:type="org.concord.otrunk.ui.OTSlider" value="0"/>
  <includes jcr:primaryType="nt:unstructured"/>
  <services jcr:primaryType="nt:unstructured"/>

Document generated by Confluence on Jan 27, 2014 16:52