Path to uv.html can now be set with options.embedTemplate

[crhallberg]

By moving /uv.html to the template, I was able to split the appUri and the hash parameters. You can now pass in a custom iframe template to set the path to uv.html.

I also utilized URLSearchParams to make the hash parameters easier to understand and update.

For example, in VuFind:

{
  "modules": {
    "shareDialogue": {
      "options": {
        "embedTemplate": "<iframe src=\"{0}/themes/vudiglib/assets/uv-4.1.0-rc1/uv.html#?{1}\" width=\"{2}\" height=\"{3}\" allowfullscreen frameborder=\"0\" title=\"{4}\"></iframe>"
      }
    }
  }
}

Admittedly, this is also possible with a RewriteRule.

RewriteRule ^/uv.html /themes/vudiglib/assets/uv-4.1.0-rc1/uv.html [R=301,L]

• Config uvAppPath (default to uv.html).

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
universalviewer	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 14, 2025 7:55pm

[demiankatz]

Thanks, @crhallberg, this is full of good ideas, but I have some suggested refinements... :-)

[demiankatz]

Rather than moving /uv.html from here into the embed template, would it be better to create a new config setting like uvAppPath that defaults to /uv.html? Then we wouldn't have to change the embed templates as much, and other code looking for the full path to uv.html would also work correctly.

I wonder if it would make sense to split this PR in two: one to do the hash parameter simplification, since I think that is a useful improvement to readability, and one to add the new config setting. Another advantage to this approach: we wouldn't have to change the number of placeholders in the embed template, which would better maintain backward compatibility.

[crhallberg]

That's a good idea. I think that getAppUri should not include /uv.html but if I'm misunderstanding the usage...

[demiankatz]

I think it's okay for getAppUri to include /uv.html -- that is part of the URL of the UV application itself. I could imagine it being useful to get the URL of the path to the application without the filename, but I think that would be a separate method that doesn't exist yet (presumably because it hasn't been needed yet). I'd be inclined to keep method names and behaviors as they are, and refactor in future if a need arises.

[crhallberg]

Alright. I switched it back. I would like to hear other opinions about this if anyone feels strongly bc I think it makes the template string harder to read and understand.

[demiankatz]

Thanks! I've marked this for steering group review so we can discuss it on a future meeting.

My view here is that getAppUri should return a full working URL to the running UV app -- and that includes the uv.html part. If we only want the path part without the actual filename on the end, I would think that would require a different method like getAppPath.

[crhallberg]

I see the distinction for sure. Having both could be the solution. Although I’d be inclined to use getAppPath for the readability in the template - which would leave getAppUri unused.

[demiankatz]

But if somebody customizes their UV to use a filename other than uv.html, we would need a way to override that.

[crhallberg]

That's what the customization of the template solves.

[crhallberg]

Didn't seem appropriate to bring it up during steering committee. Summoning @edsilv for his thoughts!

[demiankatz]

I see what you're saying. We have a to-do checkbox up above to make the actual application path a configurable option. I think it would be nice to have more granular configuration so we could configure just the piece that needs to be tweaked instead of having to copy, paste and modify the whole template (which could get out of sync over time if other things change)... but I see how either approach could be potentially workable, and the two might complement each other.