-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Make debug UI background layers configurable with new file debug-ui-config.json
#6295
Make debug UI background layers configurable with new file debug-ui-config.json
#6295
Conversation
# Conflicts: # application/src/test/resources/org/opentripplanner/apis/vectortiles/style.json
What should the debug UI be named? In the UI it is called "OTP Debug Client" and here it is called "Debug UI" - We should settle on one name. The name "OTP Debug Client" is taking up too much space. So I suggested to shorten it to just "OTP Debug" - In the UI repeating "UI" or "client" is redundant. So, maybe use "OTP Debug UI" in doc, "OTP Debug" as title in UI and "debug-ui-config.json" ? |
I'm wondering if this is a little misleading? The I guess my question is, do we want to use this config file also to configure other aspects of the debug UI or just the map styles? |
We are planning to expand its role to cover other aspects of the debug UI. |
I see, then we are looking at a way to serve this config file directly to the debug UI at runtime, since it then obviously can't be compiled into the static assets. Will it be available via a public endpoint in OTP? |
There are no concrete plans yet but I also imagine an endpoint from which the debug UI gets the configuration values at runtime. |
I'm ok with this change. My only two cents is that since we are introducing the concept configuration for the debug ui, it seems strange that we don't have a mechanism for the debug ui to fetch it. I suppose it can wait for some actual use case for that. |
We thought about using router-config.json for this particular case, but a Gitter poll showed that almost everyone preferred a separate file for it. |
@@ -14,6 +13,7 @@ | |||
import org.opentripplanner.apis.vectortiles.model.ZoomDependentNumber; | |||
import org.opentripplanner.apis.vectortiles.model.ZoomDependentNumber.ZoomStop; | |||
import org.opentripplanner.service.vehiclerental.street.StreetVehicleRentalLink; | |||
import org.opentripplanner.standalone.config.debuguiconfig.BackgroundTileLayer; |
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.
config.debuguiconfig seems like a bit of repetition (however the same repetition seems to be done for other configs as well for some reason). Perhaps config.debugui/debugclient)
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.
For go or bad, I want to follow the previous naming pattern.
If we can agree to a new structure, I'm happy to make a follow up.
@@ -0,0 +1,107 @@ | |||
package org.opentripplanner.standalone.config; |
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.
Why don't we put this inside the debugui package inside the config package (same question for other configs)?
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 have no idea and have just followed the pattern that was there before.
I would like to separate refactoring from the feature development. If we can come to an agreement how the packages should be structured I'm happy to change it in a follow up PR.
/** | ||
* This class is an object representation of the 'debug-ui-config.json'. | ||
*/ | ||
public class DebugUiConfig implements Serializable { |
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.
Is this something we want to serialize? Isn't it enough to read this in at run time? Also, should we have some common interface/class for configs?
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 removed Serializable: 8395345
I would love to refactor this class, but I request to do it in a separate PR.
application/src/main/java/org/opentripplanner/standalone/config/DebugUiConfig.java
Outdated
Show resolved
Hide resolved
application/src/main/java/org/opentripplanner/standalone/config/DebugUiConfig.java
Outdated
Show resolved
Hide resolved
…g/DebugUiConfig.java Co-authored-by: Joel Lappalainen <[email protected]>
I agree with this and have removed the word "UI" from the UI where it is indeed redundant. |
How about "OTP Debugger"? |
}); | ||
select.onchange = () => { | ||
const layerId = select.value; | ||
console.log(select.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.
Very minor, but this console.log doesn't seem necessary
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 would prefer no console.log, but otherwise ok
I removed the console.log on dev-2.x: 0079a16 |
Summary
Introduces a new file for configuring the debug UI (
debug-ui-config.json
) and adds the ability to configure the background layers.The UI for selecting the background map looks like this:
Issue
Closes #6275
Unit tests
Added a few.
Documentation
I added a new configuration page for the new config file and updated a few existing places.
Changelog
Autogenerated.
Bumping the serialization version id
No.
cc @fpurcell