search

OneZoom / OZtree

OneZoom Tree of Life Explorer
Other
83 stars 16 forks source link

Getting 'Invalid pinpoint' errors with alternate tree. Should life.html be tree agnostic? #829

Open davidebbo opened 2 months ago

davidebbo commented 2 months ago

If I run with my alternate tree, I see these errors in F12 (note: the site still seems to run ok):

pinpoint.js:123 Uncaught (in promise) Error: Invalid pinpoint770315
    at eval (VM16677 pinpoint.js:123:26)
    at Array.forEach (<anonymous>)
    at eval (VM16677 pinpoint.js:118:23)

They're caused by the hard coded locations_json list in life.html.

This brings the question: is life.html meant to be specific to the main tree? Ot should we try to have locations_json be populated more dynamically, like from configuration?

lentinj commented 2 months ago

AFAIK there isn't a solid plan for how we add multiple trees to the site architecture.

The locations aren't just dependent on tree---but one of the reasons the list is here is we also customise this list for other pages, e.g: AT.html and otop.html. I think the idea was to let partners customise their own page, including their start points.

Moving locations_json to tree_startpoints would be an option, but makes this process more awkward. And if you're doing this much customisation then you probably have a particular tree in mind anyway.

The other reason is to avoid a database hit, but IMO we should get better at caching rather than worry too much about that, given ~all our pages are anonymous.

In the short term we could have a "custom.html" that makes no assumptions about the tree it's using?

davidebbo commented 2 months ago

You're right that we'll probably end up having a custom locations_json for the extinct tree.

From a maintenance standpoint, I see there are 8 files with identical locations_json, so ideally this would be factored out into its own file and included. And when we get to a different tree list extinct, are we going to want a new flavor of all those 8 files, e.g. to support touch vs mouse?

We don't need to do anything short term, but it feels like the right solution is to better decouple 'code' from 'data', but having things like locations_json be some form of parameter that all the flavors of life.html can use.