Problem/Motivation
A lot of widget plugins are about listing something. Lists usually need some kind of pager.
There are limitations for the default pager when being in context of the entity browser since it uses GET arguments to track pages. Using the default pager will generally reload the form causing form state to be list. This is obviously not desired.
Proposed resolution
Implement a pager that supports entity browser's use case. Probably through buttons/submits. Make it look consistently with the default Drupal pager.
Remaining tasks
- Implement pager (possibly as a trait that can be used optionally?)
- Provide test coverage
| Comment | File | Size | Author |
|---|---|---|---|
| #32 | interdiff.txt | 927 bytes | slashrsm |
| #32 | 2844876_32.patch | 15.09 KB | slashrsm |
| #30 | 2844876_30.patch | 14.19 KB | slashrsm |
| #29 | 2844876_29.patch | 9.64 KB | slashrsm |
| #28 | interdiff.txt | 6.24 KB | slashrsm |
Comments
Comment #2
CTaPByK commentedInitial patch for pager. Test will be done after reviews and suggestions.
Comment #3
slashrsm commentedIt should be all lowercase. "type" doesn't sound like a standard attribute. Why this decision?
Should extensively document why this needs to exists and how is to be used.
This function needs to be called on every submit or the page number potentially won't be correct.
Could we update page number ob a submit handler on the element itself?
Comment #4
CTaPByK commentedFix suggestions from #3. Working on test.
Comment #5
CTaPByK commentedAdded some simple test coverage.
Comment #8
CTaPByK commentedUpdate patch and test coverage.
Comment #9
slashrsm commentedDocument how this element is used on a custom widget (examples, ...).
I'd default this to false.
Defaults are missing for values that are documented in the class comment.
What happens when page was not saved to the form state yet?
You most likely want to use #limit_validation_errors on this.
It might not always be possible to provide full list of entities (huge dataset, performance, ...). How do we figure out last page in that case?
Where are this attributes used?
Ok... now I understand. We need #entities_list just for figuring out last page number.
In cases with huge datasets we'll pay big performance price for that. I'd rather rely on the implementing form to pass in the total number of pages (optional).
This could be simplified a lot. I'd only put pager on the widget and display message with the number of the current page on each page load.
Then you can click pager buttons and check if the reported page seems correct + other things (buttons are disabled, ...)
If you go on /entity-browser/modal/pager instead you don't need JS (which will make test a bit faster).
Comment #10
primsi commentedLooks pretty fine. Some nitpicks:
A bit unclear. I would elaborate more.
Default entities per page.
Also isn't 5 a bit low?
static:: is preferred I think. Also applies elsewhere.
I was wandering if we should also test that listed entities actually change. Like, we have 12 items, display 3 per page and in the test assert that there are 3 specific elements on the first page, 3 others on the second ...
Comment #11
primsi commentedAs per discussion with @slashrsm and his comment above my comment about testing is not relevant.
Comment #12
CTaPByK commentedI try to fix points from #9 and #10. I hope i'm not missed something.
Comment #15
CTaPByK commentedSome fixes. I try to fix this test EntityBrowserTest.php but in my localhost this test is green.
Comment #16
slashrsm commentedThis is not correct. Those are all standalone values and have nothing to do with the #default_value one.
If you correctly declare default values for those 3 in
getInfo()you don't need to do that.I would get rid of #entities_list entirely. As mentioned in my previous review it can cause huge performance problems.
You will need to respect #parents here. It is generally possible that the pager appears deeper than top level in the form structure.
This configuration value is not used any more. Can be deleted.
Comment #17
CTaPByK commentedComment #19
CTaPByK commentedComment #20
slashrsm commentedThis seems not to be used any more.
We need to explain that this is optional and what happens if it is not defined.
Also
$element['#total_pages'] == $pagewill be true for the default value and if$pageis 0. I think that we need strict comparison here just in case.FALSE is not a very common pick for "undefined" which is what we essentially mean here if we don't provide a value. NULL is much more common in my opinion.
How do I, as a developer that is using it, find out which page I am on?
I agree with @primsi that we should give this constant a better name.
Comment #21
CTaPByK commentedFix points from #20.
Comment #23
slashrsm commentedLast nitpiks:
Leftover.
Wrap in @code.
Use @see
Comment #24
primsi commentedCan this be mixed too?
Comment #25
CTaPByK commentedFixed.
Comment #27
slashrsm commentedFixed patch so it applies and improved docs a bit.
Comment #28
slashrsm commentedAdded another helper function that resets the pager.
Comment #29
slashrsm commentedFixed a typo in
setCurrentPage()and improved tests to cover that case. I screwed the interdiff. Sorry.Comment #30
slashrsm commentedRe-added test that escaped because of the rename.
Comment #32
slashrsm commentedComment #35
slashrsm commented