-
-
Notifications
You must be signed in to change notification settings - Fork 192
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
Path to uv.html can now be set with options.embedTemplate #1254
Conversation
…ing when uv.html isn't in webroot.
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
There was a problem hiding this 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}`; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
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]>
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. |
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. |
This has been updated so that you can set |
There was a problem hiding this 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 "/" |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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, "".
There was a problem hiding this comment.
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!
src/content-handlers/iiif/modules/uv-shared-module/BaseExtension.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this 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.
This looks good on my side too. Thanks @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.
uvAppPath
(default touv.html
).For example, in VuFind:
Admittedly, this is also possible with a RewriteRule.