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

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

Merged
merged 13 commits into from
Mar 3, 2025

Conversation

crhallberg
Copy link
Contributor

@crhallberg crhallberg commented Dec 12, 2024

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.

  • Config uvAppPath (default to uv.html).
  • Switch to just uv.html.
  • Allow switching of hostname.

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]

Copy link

vercel bot commented Dec 12, 2024

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 Feb 27, 2025 4:48pm

Copy link
Contributor

@demiankatz demiankatz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


return appUri + "/uv.html";
const port = window.location.port ? `:${window.location.port}` : "";
return `${window.location.protocol}//${window.location.hostname}${port}`;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@demiankatz demiankatz Dec 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's what the customization of the template solves.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Co-authored-by: Demian Katz <[email protected]>
@mialondon
Copy link
Contributor

Documenting my comments in the stand-up, I'd lean towards the simpler solution of configuring the path (and host) and leaving the potential complexity of modifying other options for a later task, perhaps with more input from orgs where embed has been used a lot.

@LlGC-jop
Copy link
Contributor

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.

Increased granularity sounds good to me, @demiankatz

Having getAppUri() call functions to get the hostname, filename, port etc - either from provided config or defaults - would make implementation much more flexible.

@crhallberg
Copy link
Contributor Author

crhallberg commented Feb 26, 2025

This has been updated so that you can set embedHost, embedPort, and embedPath (alongside embedTemplate). See the config here.

Copy link
Contributor

@demiankatz demiankatz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @crhallberg, this is coming along very nicely! See below for a few comments/suggestions.

/** Hosting settings for embedding */
embedHost?: string;
embedPort?: number;
embedPath: string; // starts with "/"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we may need a separate comment on each property to ensure that auto-generated documentation comes out correctly.

const host =
options?.embedHost ??
`${window.location.protocol}//${window.location.hostname}`;
const port = options?.embedPort ?? window.location.port;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to add logic to leave off default ports like 80 and 443 when they match the protocol, or does this already happen automatically somehow? (I'm guessing more work may be needed, since the demo has a custom-configured port, so you wouldn't see how this behaves in standard HTTP/S by default).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like JS takes care of that for us: https://developer.mozilla.org/en-US/docs/Web/API/Location/protocol.

If the port is the default for the protocol (80 for ws: and http:, 443 for wss: and https:, and 21 for ftp:), this property contains an empty string, "".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hooray for well-designed magic!

Copy link
Contributor

@demiankatz demiankatz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this meets all the requirements now and looks good to me. I'll leave it unmerged for a little longer, though, in case others have feedback.

@LanieOkorodudu
Copy link
Collaborator

I think this meets all the requirements now and looks good to me. I'll leave it unmerged for a little longer, though, in case others have feedback.

This looks good on my side too. Thanks @crhallberg

@LlGC-szw LlGC-szw merged commit fde8d7d into UniversalViewer:dev Mar 3, 2025
5 checks passed
@crhallberg crhallberg deleted the embed-webroot-template branch March 3, 2025 13:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: COMPLETED
Status: Completed
Development

Successfully merging this pull request may close these issues.

6 participants