Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancement: internal structure for manifests should be cleaner #127

Open
azaroth42 opened this issue Mar 4, 2014 · 1 comment
Open
Milestone

Comments

@azaroth42
Copy link
Contributor

The current structure works okay for a list of single images, but is terrible for other content being rendered on the canvas, and especially detail images (which I'm trying to implement in an OSD overlay at the moment)

Given that a single manifest can have multiple sequences across the same (or at least highly overlapping) sets of canvases, my proposal is:

  • Pass the manifest object around rather than a string to avoid repeated lookups (not totally necessary, but constantly doing $.manifests[manifestId] seems pointless)
  • Manifest object has a list of sequences which contain only the identities of the canvases in the right order.
  • Manifest object also has a dictionary of canvasId : canvasObj that can be used to look up the canvases
  • Each canvas object maintains the information about the resources associated with it, in the same way that imageObj does now, but with all of the available information. Then views can do different things with that same structured information.
  • Then the views would store their manifest, sequence index and current position. From there, manifest.canvases[manifest.sequences[view.seqidx][view.position]] would return the canvas object, that maintains all the information needed to render it.

In Presentation API 1.1 this will be even more important with the addition of thumbnails, resource level licenses, attribution and other metadata, and so forth.

@azaroth42
Copy link
Contributor Author

Oh, and the manifestsLoader trick of trashing the manifest object and making a very similar looking dictionary ... cute, but will waste many many many developer hours. (count starts at 1.5 so far :P )
Marked: PlzFix

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants