-
Notifications
You must be signed in to change notification settings - Fork 772
Support specifying custom URLs for resources #8229
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
Conversation
|
@JamesNK right now the dashboard is not showing URLs that aren't associated with an endpoint in the resource details grid as there's currently a requirement for property grid items to have a name as that's used as the key. @davidfowl is suggesting we change the current "Endpoints" grid to instead just show URLs, and re-think the columns to match, but we'll need to figure out how to handle items with no name. Would appreciate your help there. I guess we might want to revisit the column header in the Resources page too, i.e. change "Endpoints" to "URLs". |
|
I think we change "Endpoints" to "Urls" everywhere. Edit: However, there can be TCP endpoints which aren't Urls. It would be a little weird having a column called "Urls" that then contains values like In the resource details we could change the columns to: "Link" and "Endpoint name"
Anything can be the row key, as long as it is unique. I'm guessing it is possible to have the same URL multiple times so that couldn't be the key. There wasn't a good key for volume so we used the index of the volume instance in the collection as the key.
I think you could do the same thing here. |
| <AspireTemplateColumn Sortable="true" SortBy="@(GridSort<DisplayedEndpoint>.ByAscending(i => i.DisplayName))" Title="@ControlStringsLoc[nameof(ControlsStrings.DisplayNameColumnHeader)]"> | ||
| <GridValue ValueDescription="@ControlStringsLoc[nameof(ControlsStrings.DisplayNameColumnHeader)]" | ||
| Value="@context.DisplayName" | ||
| EnableHighlighting="@(!string.IsNullOrEmpty(_filter))" | ||
| HighlightText="@_filter" /> | ||
| </AspireTemplateColumn> |
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'm not a fan of having the URL and display name as separate columns. I'd rather there was just a "Link" column which displayed a hyperlink. If there is a display name then it is the text for the link. If there isn't then use the URL.
Opening the text visualizer or copy would use the URL value.
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.
Hmm, but there could also be values that aren't links, e.g. tcp://localhost:8080. Maybe link isn't the right header
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.
OK so we're saying back to two columns. "Endpoint name" is one of them and I think that's clear. The second one will contain the hyperlink if it's a URL, otherwise it will just be the URI text. Do we simply give it a combo name like "URI / Link"? Or should we just settle on "Link" and not worry too much about the non-hyperlinked URI case?
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 lean towards the latter option
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.
@adamint just go with "Link"?
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 went with "Link", take a look in the video in the PR description.
| var url = context.Urls.FirstOrDefault(u => u.Endpoint?.EndpointName == endpointName); | ||
| if (url is not null) | ||
| { | ||
| url.DisplayText = Resources.DataExplorerUrlText; |
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 don't think this will work, because the requesting browser may be using a different locale than hosting. I think it should go in the place I linked before
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.
Ah right. We need this to be localized in the dashboard itself then, as a known 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.
Right. I'm concerned just using the endpoint name will be too broad, we could use a combo of resource type + endpoint name? But since AzureCosmosDBEmulatorResource is just a container resource.. we can't use the resource type. Am I missing something or do we need to add a more specific identifier too
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.
OK rigged it up.
src/Aspire.Hosting/ApplicationModel/ResourceUrlsCallbackContext.cs
Outdated
Show resolved
Hide resolved
| // The name of the url | ||
| string name = 1; | ||
| // The name of endpoint associated with the url | ||
| optional string endpoint_name = 1; |
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.
FYI this change to the proto is binary compatible. It's ok to make
|
@mitchdenny @davidfowl There is a lot in this PR. I'm focusing on dashboard changes and taking a brief look at hosting changes. It would be good for hosting experts (ya'll) to double check hosting changes. |
Given the column order will be reversed so the link is first and the endpoint name second, and I'd expect the link to be longer than the endpoint name in most cases, do you still think it makes sense to have the column widths match that of a standard name/value property grid? |
|
I don't think either of them will be that long. A good URL display name will be short so it fits in the main grid so it should fit here. And most values here will still be the underlying URL anyway. I think the consisency of grid widths, i.e. looking good, trumps showing a bit more of very long display names IMO. |
I'm not sure I agree but I'm fine with making them match until such time that we see evidence of it being a problem. |
| var text = endpoint?.Url; | ||
| if (string.IsNullOrEmpty(text)) | ||
| { | ||
| return "No endpoints"; |
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.
This should say "No URLs". And while you're here, could you move the text to a resource file. I should have done 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.
Actually the resource graph only looks at endpoint-associated URLs right now. When it was showing all URLs it would pick the first one and then show the display text un-hyperlinked which wasn't useful at all. Having it show the actual endpoint address is more useful IMO.
| var url = context.Urls.FirstOrDefault(u => string.Equals(u.Endpoint?.EndpointName, endpoint.Name, StringComparisons.EndpointAnnotationName)); | ||
| if (url is not null) | ||
| { | ||
| if (launchUri.IsAbsoluteUri) |
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.
Follow up: Discuss if an absolute launch urls wins over all over urls and becomes the only ones that shows up.
|
|
||
| internal static class KnownUrls | ||
| { | ||
| public static class DataExplorer |
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.
This is the most .NET thing ever. Why is this shared it's cosmos specific.
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.
Cos localization has to happen in the context of the dashboard. We do this for known commands too. We can add stuff to this for any other known link text we want to localize.
davidfowl
left a comment
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.
@DamianEdwards do a follow up and fix the AzureProvisioner to use this for deployments
@davidfowl can you elaborate? Which URLs should the provisioner use exactly and for what scenarios? Maybe put details in an issue? |



Description
This change introduces support for resource URLs. Resource endpoints get automatically projected into URLs, which can be customized, and extra URLs can be added that aren't associated with endpoints at all.
Fixes #6457
Fixes #7104
Fixes #4319
Contributes to #5209
Screen.Recording.2025-03-21.125917.mp4
Checklist
<remarks />and<code />elements on your triple slash comments?doc-ideatemplate): [pending]