Closed (fixed)
Project:
Translation Management Tool
Version:
8.x-1.x-dev
Component:
User interface
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
14 Jul 2015 at 07:28 UTC
Updated:
18 Aug 2015 at 19:24 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
juanse254 commentedComment #2
juanse254 commentedUncommented line and fixed relating to issue #2529610: Validation errors shown repeatingly also test added.
Comment #3
juanse254 commentedComment #7
juanse254 commentedFixed failing test.
Comment #9
juanse254 commentedFixed commented method which was not working. Added Test as well
Comment #10
berdirWhy do you need to get the value from $form? And you shouldn't use $_POST, again, use $form_state->getValue().
Comment #11
juanse254 commentedI had to use $form instead of $form_state because $form doesnt add the value to the array if it has not changed while $form_state fills the array with the options and if one is chosen sets its value to 1 else the value is set to 0. Therefore i would have to check that all elements of the $form_state->getValue('items') are set to zero in order to know if no values are chosen.
Added fix for Post.
Comment #12
juanse254 commentedComment #13
berdirDid you try array_filter() on getValue() ?
Comment #14
juanse254 commentedOkay, that worked :).
Comment #15
sasanikolic commentedBased on the coding standards, I would separate these two words in the variable with an underscore. It is much easier to read that way.
Comment #16
juanse254 commentedFixed with comment 15.
Comment #17
sasanikolic commentedSorry, you're missing a dot at the end of the sentence. :)
Comment #18
juanse254 commentedNew patch, please try to review it all at once so i dont have to create tons of patches on syntax changes.
Comment #19
mbovan commentedComment #10 from #2511822: False past broken info on status report :)
I guess you can use
$form['search_wrapper']['search_submit']['#value'] == $form_state->getTriggeringElement()['#value']so we don't need to translate new Search again.Btw, there is a Cancel button which displays "You didn't select any source objects" when triggered. Is this Cancel about translation or filters? If it is like Search, then I think we should do the same for it.
You can use
!$itemsinstead ofempty($items).Comment #20
juanse254 commentedFixed 2, 3 and also added coverage for the cancel button which is not always present. i left 1 because i have a single quote inside of the string so maybe using double quote will be better in this case.
Comment #21
juanse254 commentedComment #22
LKS90 commentedIs always true?
Remove that, also looks nicer than two nested if statements.
Comment #23
juanse254 commentedThis is actually an issue since in /admin/tmgmt/sources/locale/default the cancel button is not shown. Im uploading the patch and creating a followup since the test have to be fixed, after that the patch will be positive.
issue #2535190: LocaleSourceUITest testing wrong path in value
Comment #25
mbovan commentedI think you have to check if
$form['search_wrapper']['search_cancel']exists before calling the child element.Comment #26
juanse254 commentedIn the issue posted in comment 23 it states that the search_cancel must always be present. Therefore until the patch gets commited, its pointless to check if the search_cancel exists since it must always exist.
Comment #27
juanse254 commentedRebased the patch for applying.
Comment #28
berdirNot really happy about this.
We fixed locale now but this still means we have hardcoded assumptions that those form elements exist.. there might be a source that doesn't even have a search.
We could make it conditional I guess, but what about turning this around...
We could move it to overviewFormValidate() in the plugin Ui base class.
Or, what if we add a validateItemsSelected() method to the baes class and explicitly add it to the buttons that actually want it? Combined with unifying that part into the base class, that would make it standardized but still overridable.
Comment #29
juanse254 commentedOkay, added to the overviewformValidate() and added to sourceoverview as well. Test included.
Comment #30
berdirHow is that we have two different messages here?
The same validate needs to be added to the add to cart form.
Still not cleaned up.
This is not needed?
Comment #31
juanse254 commentedComments taken into account.
Comment #32
mbovan commentedI would rewrite this as:
Same for
submitForm()Method documentation seems wrong?
Are the both methods (with same code) needed? If yes, can we call
tmgmt_cart_source_overview_validate()fromvalidateItemsSelected()and avoid code duplication?Comment #33
mbovan commentedComment #34
juanse254 commented1.- Has nothing to do with the issue.
2.- Applied.
3.- Applied.
Comment #35
LKS90 commented$this->drupalPostForm(NULL, [], t('Search'));is shorter and consistent regarding the array syntax. Leave the path in the first drupalPostForm, replace the rest with NULL (since we already are on that page), switch the array()'s to [].Comment #36
juanse254 commentedDone.
Comment #37
juanse254 commentedForgot to rebase, my bad.
Comment #38
LKS90 commentedanother
array()The interdiff is something, but not an interdiff :P.
Comment #39
juanse254 commentedMy bad, fixed that and added right interdiff.
Comment #40
LKS90 commentedLooks good now.
Comment #41
berdirA #validate on a details element doesn't do anything?
This is a bit weird but OK, can live with that.
Comment #42
juanse254 commentedDone :).
Comment #43
mbovan commentedI guess then this change is not needed.
Comment #44
juanse254 commentedDone
Comment #45
mbovan commentedSeems fine.
Comment #46
LKS90 commentedLooking good now.
Comment #47
berdirOk, committed, thanks.