Aliases for Target Hosts #334
Conversation
- obselete json parsing - new host default port
removed unused funcions; do not reset picked host after edit if it still exists handle no target hosts situation deserialize port from json
|
Could you please use standart library classes IPEndPoint and IPAddress? I think it's better then writing own serialization and deserialization methods |
I believe, what we need here, is simple and maintainable structure which represents remote host (ip and port in our case). I don't see the case for using more complicated data structures than that. Besides, do you suggest serialization of such classes to json-config, or creating yet another conversion to a custom format for that case? I can consider using library classes, but can you please describe how exactly that approach would make current serialization/deserialization easier? Thanks:) |
|
Marked as
WIP
|
Fixed in 8084564 Remove
WIP
|
…seamless migration from old configs
Resolves #332
Reworked Target Hosts edition dialog (see image). Now host and port are separate fields (latter will be set to default
9339when new host is added), and also we have optionalAliasfield. If set to non-empty, this host will be listed by its alias in dropdown.User still can manually enter new host to the hosts dropdown in format
ip:port. User input is carefully handled - if there is such host, but wit alias, alias will be used. If user just enters known alias, corresponding host will be used.The last, but not least, this PR contains a work on refactoring the logic of storing and using current target host. Before, there were a lot of duplication of essentially same info (string
ip:port, stringipand ushortport,HostItem,ServerConnectionOptions...), now it is standardized and much easier to understand and extend (f.e. add an alias). Also,RemoteMachineandPortare gone from project config, since this info is already stored inTargetHosts, which works like MRU collection.