Converts Edge/Mid header rewrite, regexremap, remaptext and tr request/response header text inputs to textareas#3474
Conversation
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
I am +8 million on this |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
992f208 to
5badaff
Compare
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
There was a problem hiding this comment.
I don't really think it's necessary to update the docs for a dead UI :P
Not that I'm saying you should revert this - it's fine, just for future reference.
There was a problem hiding this comment.
yeah, people still might stumble here so i updated it. we need an effort to purge everything old TO UI related however.
There was a problem hiding this comment.
This regex eats all whitespace around a __RETURN__, which turns out to be unnecessary. Later as the values are iterated over they are individually trimmed anyway, so strings.Split works fine. Of course, you still wanna split on newlines instead of just __RETURN__, so you probably wanna use strings.Replace first to turn all of those into newlines.
There was a problem hiding this comment.
yeah, you're right, it's redundant as it trims later. removed that.
There was a problem hiding this comment.
semantically a <fieldset> encloses a set of controls, of which the "Current Value" is not one. Plus the current value is totally immutable, so not very well represented as an <input> - even if it is readonly. Honestly I think <small> was fine here, but you could also use an <output> (optionally with a <label>).
There was a problem hiding this comment.
"The <output> tag represents the result of a calculation (like one performed by a script)."
that's a definition I found so not sure output is the right answer but i did try it and i was getting weird wrapping issues if the value was long.
as far as styling, i was just looking for the look of a disabled input/textarea and those elements give me that by simply using the readonly attribute. whereas, if i wanted to use small i'd have to wrestle with some styling.
and yeah, the fieldset, though probably not technically the correct element, was simply used to achieve the style/layout.
There was a problem hiding this comment.
I'm not sold on <textarea> either, since it's defined as an editing control that gets submitted along with the parent form. Not that we actually do form submission, but semantically user-agents will expect that it is an input control that simply cannot be changed. You could try <pre> or <samp> instead.
Technically anything that would be a previous value is the result of some user's actions, but not necessarily recently, or by the current user, or even using the TP UI at all. Plus, a previous value can only exist if there's a new current value. So maybe <output> isn't the best way to represent it, but I could see an argument for it.
Styling of a fieldset appear consistent across Chrome, Firefox and Safari so there doesn't really seem to be any harm in using it (unless you want its contents to display with flex or grid, which is bugged in Edge and Chrome). My only concern is that it appears to the user-agent as a set of grouped controls, and actually does contain <input>/<textarea> form controls that aren't really part of the form.
There was a problem hiding this comment.
let me try pre or samp
There was a problem hiding this comment.
This rule doesn't actually match anything as far as I can tell - though I could've missed something. The <textarea>s seem to only have the readonly class. But you don't really need either of them, since the things you're trying to style will match textarea[readonly][autosize].
There was a problem hiding this comment.
This matches the following elements in the ds forms:
<textarea id="edgeFQDNs" name="edgeFQDNs" rows="{{deliveryService.exampleURLs.length}}" class="form-control autosize" readonly>{{edgeFQDNs(deliveryService)}}</textarea>
but i made a change to _form.scss to use the pseudo selector read-only and removed the readonly class.
There was a problem hiding this comment.
autofocus doesn't make much sense on a control that's halfway down the page and hidden in an "Advanced" submenu. type="text" is also meaningless on a <textarea> element.
|
Most of my comments apply to several dozen repeated areas, but to avoid spamming the PR I just made each comment once. |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
ocket8888
left a comment
There was a problem hiding this comment.
Missed this - there are actually a few flubs like this in the changelog file. Should probably open a PR to fix that - or is that considered editing history?
CHANGELOG.md
Outdated
There was a problem hiding this comment.
This is markdown, so the __s on that __RETURN__ are gonna get eaten as formatting - wrap in backticks to make it pre-formatted.
…eserve line breaks and eliminate the need for __RETURN__
… more investigation
…ine values are displayed.
…ced with \n and than the full value of tr_request/response_header is split on \n
…rmed subsequently already
5cc2dfe to
f22cc8a
Compare
| position: relative; | ||
| border-radius: 4px; | ||
| background-color: #f5f5f5; | ||
| padding-left: 10px !important; |
There was a problem hiding this comment.
were border and padding-left being overridden by something?
There was a problem hiding this comment.
nope. i'll fix that. i was just copying some stying from the fieldset
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
| <small class="input-diff" ng-if="settings.isRequest" ng-show="open() && deliveryService.active != dsCurrent.active">Current Value: [ {{dsCurrent.active ? 'Active' : 'Not Active'}} ]</small> | ||
| <aside class="current-value" ng-if="settings.isRequest" ng-show="open() && deliveryService.active != dsCurrent.active"> | ||
| <label for="current-value-active">Current Value</label> | ||
| <pre id="current-value-active">{{::dsCurrent.active ? 'Active' : 'Not Active'}}</pre> |
There was a problem hiding this comment.
<pre> tags are not labelable, so if you wanna use those you should maybe change the <label>s to <h3> (I think that's the appropriate level without looking - basically <h{{n}}> where n is one greater than the lowest-level section heading already used in the document) and getting rid of those for and id attributes.
There was a problem hiding this comment.
yeah, i can switch to <h{{n}}> but i guess i'll just pick n because there are no other instance of header tags used in the document except h6
There was a problem hiding this comment.
odd, I swear there was at least one. In general you're not supposed to skip levels, but I think it's fine since h1 and h2 don't really seem appropriate at that level.
|
Refer to this link for build results (access rights to CI server needed): |
|
@ocket8888 - thanks for the code review / suggestions. were you able to confirm the expected behavior as outlined in the description? |
|
yep, it all appears to still work. |
By converting the edge/mid header rewrite, regex remap, remap text and tr request/response header fields of the DS forms to textareas instead of text input, line breaks can be preserved and eliminate the need to use an explicit
__RETURN__to indicate a line break. (although__RETURN__will still be respected and recognized as a line break for backwards compatability).This PR also changes the presentation of delivery service request diffs to account for multiline values.
Which Traffic Control components are affected by this PR?
What is the best way to verify this PR?
Run the TO unit tests -
cd trafficcontrol/traffic_ops/traffic_ops_golang
go test $(go list ./...)
Run the API tests - https://github.com/apache/trafficcontrol/blob/master/traffic_ops/testing/api/README.md
Run the UI tests - https://github.com/apache/trafficcontrol/tree/master/traffic_portal/test/end_to_end
a. set dsRequests.enabled=true in traffic_portal_properties.json and restart TP
b. in TP, create/edit a dns* (you can do http*, steering or any_map as well but only some field apply to each) delivery service and modify the edge/mid header rewrite rules, regex remap, remap text and tr request/response headers to include multiline rules.
c. save the changes which will create a ds request.
d. review the ds request and fulfill it. fulfilling the ds request persists the ds changes to the database.
e. verify the contents of the header rewrite files and ensure the multiline rules are presented on separate lines:
edge header rewrite rules can be viewed by GET api/1.4/cdns/cdn-name/configfiles/ats/hdr_rw_xml-id.config
mid header rewrite rules can be view by GET api/1.4/cdns/cdn-name/configfiles/ats/hdr_rw_mid_xml-id.config
f. verify the contents of the regex remap config file and ensure the multiline rules are presented on separate lines:
GET api/1.4/cdns/cdn-name/configfiles/ats/regex_remap_xml-id.config
g. verify the tr request/response rules show up in the snapshot correctly
GET api/1.4/cdns/cdn-name/snapshot (current snapshot)
GET api/1.4/cdns/cdn-name/snapshot/new (next snapshot)
Note: we don't currently have any API tests to parse and validate the contents of config files.
The following criteria are ALL met by this PR