[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: PNG File pagingExample.png     PNG File selectComponentExample.png    
Issue Links:
Relates
causality
relation
is related to MGNLUI-3438 filterMode on Select-Fields has no ef... Closed
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.
Besides, from the UX stand point, if you happen to need such paging in a plain select, then it's probably the wrong control in the first place.

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.
Can you maybe elaborate on what your use case is? If you do need that kind of low-level Vaadin customization, I'd say extending the select field is the way to go.

Cheers,
Mika

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.
On the other hand, I do recognize that configuring and wiring those little things can still be improved; I'm always looking for ways to help using Vaadin skills more directly and more easily inside Magnolia (without necessarily having Magnolia playing the facade for it).

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

Generated at Mon Feb 12 09:05:12 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.