TOC module does not order correctly

[thehabes]

Hey all, I came across a bug today in the viewer. I have a range assortment like so

Table of Contents (root) Section 1 Section 2 Section 3 Section 4 Section 5 Section 6

Each of those sections have varying amounts of child ranges.

Mirador is displaying it as

Table of Contents(root) Random orders, depending on the last changes I made to the data set.

When I look into the Network tab for the response of the manifest, all of the data relationships are correct. However, Mirador populates the children based on the order they were returned from the server. My response for the manifests contains the structures field which outputs

0: Table of Contents
        ranges:[Section 1, Section 2, Section 3, Section 4, Section 5, Section 6]
        within: root
1: Section 1
        within: Table of Contents
.
.
.
12 : Section 3
        within: Table of Contents
13: Section 4
        within: Table of Contents
14 : Section 2
        within: Table of Contents
.
.
.
25 : Section 6
        within: Table of Contents
26: Section 5
        within: Table of Contents

Mirador then displays the data set as:

Table Of Contents Section 1 Section 3 Section 4 Section 2 Section 6 Section 5

This happened many different ways, in many different orders depending on the last changes I made to the data set. One thing is always consistent; it always orders things based on the response from the server, not the assortment the data is providing.

I suspect that this is because the 'within' property is used to build the structure from the lowest children to the root. I have a page that does this same thing but builds the structure from the root down to the children. I use the ranges:[] property to build the order so that how it is returned from the server does not affect the order of display. Users are asking why the order is different in the viewer than as it is displayed on my other page.

[rsinghal]

@thehabes, do you have a sample manifest we can test with that does this?

[thehabes]

Yes, use this API call to get the manifest: http://165.134.241.141/brokenBooks/getManifest?username=debra

The Mirador rendered version can be found at http://165.134.241.141/brokenBooks/getManifest.html

We had to trick the server into making it mostly appear in order. Any time we save a new range or canvas and order it, the order is not preserved. You will see this happen with a range named BB-Llang_0065, which appears before BB_Llang_0001 in the range named Temporale even though BB_Llang_0065 is 64 positions in the array after BB_Llang_0001 but is returned by the server before BB_Llang_0001. You will also see that its canvases appear last in the thumbnail strip, which does not reflect the order displayed in the TOC.

Check the console log, I log out the order the ranges are returned to me from the server, and you will see how it always builds off that order, not the order implied by the ordering principle of the ranges:[] field for a range that includes the ranges inside of it in order.

If you need me to make it a little more messed up so the problems are obvious, let me know.

[rsinghal]

related to #94

[thehabes]

I have tested and this bug has been reaffirmed: I have this range appearing in the TOC:

http://165.134.241.141/annotationstore/annotation/56292d88e4b0204a9751401b

You will see that it has some children, the last of which is

http://165.134.241.141/annotationstore/annotation/56423115e4b0c3defe2e2b5f

in the ranges[] array. However, in the TOC in Mirador ...e2b5f appears as the first child range of ...1401b

The manifest sits at: http://165.134.241.141/brokenBooks/getManifest?username=debra. **These images are not IIIF, so it will most likely fail in your viewer.

The Mirador viewer with the manifest loaded with the bug is at: http://165.134.241.141/brokenBooks/getManifest.html

[rsinghal]

duplicate, so closing