Fix the placement of form buttons on the ops screens #1500
Conversation
skateman
changed the title
skateman
force-pushed
the
form-buttons-div-fix
branch
from
5421e99 to
4aa69e1
Compare
skateman
changed the title
|
@martinpovolny can you take a look? It would require some clicking in the UI on variuous form/paginator/gtl places... |
| } | ||
| if (toolbar.find("*:visible").length > 0) { | ||
| height += toolbar.outerHeight(); | ||
| height += toolbar.outerHeight() ; |
|
@skateman : the code and the explanation look correct. @h-kataria : can you, please, take a look? Generally we need get rid of this. The buttons should be part of the form and we should not be doing any crazy stuff such as inserting buttons into every page and then showing/hinding them or having 2 sets of buttons enabled/disabled. We need to carry on removing these "magic" traps from the code. And of course if we have partial called "pagination" is should never include form buttons... |
skateman
force-pushed
the
form-buttons-div-fix
branch
from
4aa69e1 to
bc15616
Compare
|
Checked commit skateman@bc15616 with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0 |
The reason they were separated was we didn't want the user to have to scroll down to find the form buttons (i.e. they only change the name field at the top and nothing else) and we couldn't figure out how to "lock" them to the bottom of the div (at least at the time). If we can make a solution that does that for us, I'm all in! |
|
verified, fixes missing form button issues in UI. These explorers are special cases where we didn't have GTL/pagination since we don't expect lists to be longer. Height for the main_content div was being calculated using paging_div which did not exist in this case. |
|
@dclarizio : in this case I would love to have some guidelines. I see in patternfly doc and in angularized forms that the buttons are part of the form. Is that something we are generally going to do or do we want to keep the functionality of form buttons on a fixed place in some parts of the app (to save users from the scrolling)? If we want to keep that we might just clean it up and make sure that it's done the same on all pages. |
|
@martinpovolny perhaps we should discuss with @serenamarie125 . . . just thinking we might get some push back from users if all of a sudden they have to scroll to the form buttons |
Before this got broken, the
#paging_divcontained the#form_buttons_divand the JS adjusted the parent's position only. As the#form_buttons_divis no longer the child of#paging_div, I had to adjust the JS with an extra test for the buttons' visibility.This is a not very clean solution, but I will revisit it when refactoring the HTML layout + CSS styling of the right cell.
Fixes #1497