[MGNLUI-3297] Allow for disabling of paging on select field dropdown Created: 15/Dec/14 Updated: 14/Nov/18 Resolved: 19/Feb/15 |
|
| Status: | Closed |
| Project: | Magnolia UI |
| Component/s: | forms |
| Affects Version/s: | 5.3.6 |
| Fix Version/s: | 5.3.8 |
| Type: | New Feature | Priority: | Neutral |
| Reporter: | Richard Gange | Assignee: | Mikaël Geljić |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | support | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| Template: |
|
||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||
| Date of First Response: | |||||||||||||||||
| Description |
|
Allow for the disabling of paging on the select field dropdown. From what I have seen in my investigation is that we could introduce a pageLength private member in info.magnolia.ui.form.field.definition.SelectFieldDefinition. Add the appropriate getter/setter as well. Then in the info.magnolia.ui.form.field.factory.SelectFieldFactory class we could add a line to the createFieldComponent() method which uses the setPageLength() method from com.vaadin.ui.ComboBox. Like this: ((ComboBox) select).setPageLength(definition.getPageLength()); This would then allow a user to configure the page length to 0 which turns off paging as noted in the class com.vaadin.ui.ComboBox. /** * Holds value of property pageLength. 0 disables paging. */ protected int pageLength = 10; |
| Comments |
| Comment by Mikaël Geljić [ 19/Feb/15 ] |
|
Paging is just the Vaadin default for the ComboBox component. We don't have any apparent need for it though, so we'll simply turn pagination off. In other words we don't make that configurable. |
| Comment by Michiel Meeuwissen [ 27/May/15 ] |
|
I find in SelectFieldFactory now the following:
((ComboBox) select).setPageLength(0);
It seems that I cannot set the page length at all any more. I ended up extending it to get this working again. |
| Comment by Mikaël Geljić [ 27/May/15 ] |
|
Hi Michiel, My previous comment explaining the rationale for this change was not publicly visible somehow, so I just changed that. Cheers, |
| Comment by Michiel Meeuwissen [ 27/May/15 ] |
|
I simple have a very long combobox. With 250 entries or so, which really displays badly without paging. I generate the combox-box options from the values of an enum (for that I needed to extend OptionGroupFieldDefinition). public class ChannelSelect extends OptionGroupFieldDefinition { public ChannelSelect() { setOptions(createOptions()); setSortOptions(false); setMultiselect(false); setFilteringMode(1); } private static List<SelectFieldOptionDefinition> createOptions() { List<SelectFieldOptionDefinition> options = new ArrayList<>(); options.add(new OptionBuilder() .label("-") .value(" ").definition()); for (Channel channel : Channel.values()) { options.add(new OptionBuilder() .label(channel.toString()) .value(channel.name()) .definition() ); } return options; } } I actually don't see the point of making a different decision than vaadin itself did. They think that pageLength needs to be configurable, and I suppose they know what they are talking about. So why isn't it in SelectFieldFactory/SelectFieldDefinition? Of course, I can simply extend it, as I have done now, but I must say it is a bit annoying. I end up making many classes to do quite simple things. One setter, and I wouldn't have to, which would have been less cumbersome. But anyhow, I think that I will not be ready with this either, because the performance of a form with a select of 250 entries is, even they are paged, too bad to be actually useable. I'm now looking into that. Perhaps I need to somehow lazy load those options or so. |
| Comment by Mikaël Geljić [ 19/Apr/16 ] |
|
Just a late update on this one: pageLength was eventually added to SelectFieldDefinition, as early as 5.3.9 (see related ticket), for slightly different reasons though. I was not questioning Vaadin's choice of defaults, but in the Magnolia case, options are typically configured. As such, There are hardly cases where you'd have even just a hundred configured options. When that is the case, the "factory way" seems indeed to be a better fit than the configured way. I'm still convinced it's much easier for devs to explicitly use paging for these cases (given you need the factory anyway), as it would be for admins to disable paging when they had 11 configured items. Just for the open discussion, I'm personally not fond of mirroring each and every Vaadin property into our definitions; we shouldn't even imply that we're specifically using a ComboBox for that matter. By the way, SelectFieldFactory is still a bit limited Container-wise; not sure you could have gone much further with performance, without overriding as well #createFieldComponent and set the Container as datasource more freely there... Better late than never |