New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"nullable" option for sap.m.Select and similar controls #409
Comments
|
We've had similar requests and such an item is already on the backlog. For the Select, we'll probably only be able to include a "dumb" option which adds an "empty" value independent of any settings on the OData service. This is because the control is unaware of the metadata of the data-binding. I can't give a concrete timeline when this will likely be implemented. |
|
I second this request. |
|
I also support this request. This is really needed! |
It is possible, if the empty option is in the data model.
Could you explain why this introduces a lot of runtime overhead and code?
We should design for change, adding features to a control that only work in a particular context (OData) is not a good idea. |
True. But what if you're consuming OData services which you haven't authored and are not under your control? All the hassle with manipulating the collection before it is rendered...a waste of time in my oppinion. On other frameworks (C++ MFC, .NET) this option is also available.
Could you explain why this enhancement would only work for OData models? |
I agree on the problem, but I'm not sure there is a reasonable way to fix that. Currently, it is not possible to add a new entity to the model via oSelect.addItem(new sap.ui.core.Item({
text: ""
}));
In the initial request, the OData annotation approach is mentioned. If you consume an OData service, which is not under your control, you would not be able to set the |
But "empty option in the model" is a really bad design. My model should represent my data. The option I'm asking for in this issue is a "default null, please pick something" option which has nothing to do with my business data but is a artifact just needed to get the UI right. You're right when saying that this should not depend on a setting on the OData service. But why would only work in OData services? Whether I use a JSON, XML, OData or WhateverModel does not change the data this model should represent. The 'default-null' option is not part of my business data but may very well be part of my UI. That's why I want to define it in the UI.
Well, If you use an ODataModel and want these null-options (which, again, are not part of your business data) you have to copy this list to (for ex.) a JSONModel, add the null-option and use this for data binding. |
|
From the architectural perspective, IMHO it not a good idea to mix dummy data (data that is not in the model) with real data in the same aggregation. Having an aggregated data item that is not in the model is an ugly and bug-prone thing. All required code to work around this mismatch will most likely cause issues again in the future, plus it is confusing. Therefore, I am not sure we want to go there. Possible alternatives:
|
|
@ArleyTriana Again what I wanted to solve with issue are the following two cases: The difference between both cases would be, technical, that in (a) For (a), adding it to the model is, IMHO, not a solution at all. Its not an option, its just something that represents that nothing is selected yet. For (b) there may be cases where it would be possible to add it to the model but again, "nothing" (as in I somewhat feel that we are talking about different things, maybe a small (made up) example can explain my thoughts: Case (b): Imagine a "Create new Project" mask that lets you select a "Project Leader" but its optional. The list would be filled with all Employees (filtered by something) so you can select a leader. But the option "no leader" should never ever be part of you EmployeeCollection. Right? I might add that the use cases of (a) might be rare (and example sounds awkward) but i've definitely seen uses for both of the cases. Back to your question: Yes, the "forceSelection" option would help, solving at least the (a)-cases. |
|
I also second this (I wanted to write an issue on this myself). |
|
Just tried with forceSelection=false in 1.34.6 and obviously nothing is selected at first, but when the user has selected an entry, the selection can't be removed anymore. |
|
I'm also interested in this feature. I had this requirement already several times in customer projects. |
|
Even though this solution is not great, I managed to get the empty field stick by adding both, the forceSelection=false property, and also in the controller's onInit function (I used the Select element): If the forceSelection=false is left out, the field will load either too early or too late to the drop down, which will cause the wrong selection to be visible. Hope it helps someone. |
|
I'm interested in seeing this implemented as well. It would be very useful for our business needs. |
|
I would be interested in a feature for this for Select controls as well. I was able to get around this by creating my own control ZNullableSelect to contain a placeholder. It uses forceSelection=false and adds a placeholder property which can use binding or set directly as string. I haven't tested if it works with two way binding but it works for the most part If using JS. Import with "sap.m.ZNullableSelect" and create a new ZNullableSelect. For Example: |
|
If I understand correctly the whole thread and comment, the desired feature is to have a dummy item with “empty value” in the sap.m.Select control’s options. Questions to everyone:
|
|
1: null (and this thus will only make sense for nullable bindings), just look at the title and description of this issue.... |
The alternative way is to insert a null value to a model and bind it to the select control. If using an OData model you could add a null value to the odata webservice read set and use a formatter function to swap the null Item text with a placeholder |
|
The Select control lists what is in data, and if you add validation that selectedKey must be set, the user will set it just to pass the screen (I've seen it and I've done it :D) The default value of selectedKey is empty string, if the property is not set or updated via interaction. In different cases will appear issues like not knowing that data already has a record with empty string as key, or that a scenario relies on the default value of the select. That is why an Input with valueHelpOnly or ComboBox with validation appears better in my mind. |
|
This nonsense, how should an odata query returning the valid values include an null in the returned values? Note that null means no value set! |
|
Just adding my 👍 here again. My opinion from my last comment still holds as this is only partially solved. |
|
I'm here for the same "issue". |
|
A search for this issue got me to this page and I have to say I agree that there should be a default, empty option for a Select. In case they've selected something in a non-mandatory Select, they can't revert this. Regarding sending null options in OData requests, imagine you're working with an SAP BE system and you have the Select binded to an Entity where the key of the Select is also the key of the Entity. Regarding using a combo box, according to SAP Fiori Guidelines, those should be used in case you have very large set of options. For smaller sets, a Select is recommended. Cheers, |
|
Long ongoing discussion. I've created an internal incident 2270008434 to bring this topic up again. |
|
This enhancement request will be covered in backlog item BGSOFUIPIRIN-5647. |
|
Hello @themasch and @DerGuteWolf, Is this still a relevant issue? Can you confirm? Thanks and best regards, |
|
@jdichev I cannot say much to this, as I have not touched OpenUI for a few years now, nor any other frontend code for that matter ;) |
|
@jdichev IMHO this is still relevant! |
|
@DerGuteWolf thanks. We're looking into the issue |
|
Hi @DerGuteWolf, sap.m.Select control is design to allow user to choose from a list of options. As native select when sap.m.Select is used there should be always selected option even if the value of selected option is null. We recommend to add additional option to the list with empty value and text that encourage user to do a selection (please check https://experience.sap.com/internal/fiori-design-web/select/#option-list1). forceSelection property is not a solution for this issue and as you can see our documentation we recommend to use it for better interoperability with data binding not for initial empty state. If you want to have initially empty value for sap.m.Select we recommend you to replace it sap.m.ComboBox. |
I'm not 100% sure that this is not a duplicate but couldn't find a matching issue so I'll create a new one. If this has been discussed earlier: sorry!
I've seen many cases now where we'd like to be able to tell a sap.m.Select that there should be a (default selected, always top-of-the-list) empty option. Selecting this would set selectedItem and selectedKey to null, trigger the change event etc. The OData annotations and metadata allows to mark a field as "nullable" which doesn't work well with current selects.
Currently our workaround is to include these empty options in the Model used for the binding but this introduces a lot of runtime overhead and code.
The API could look somewhat like that:
Add two new properties:
nullabledefault falsenullableTextdefault "" // someone should be able to come up with a better name..Somewhere between binding and rendering (updateItems?) there would be an additional "virtual" Item created that uses the
nullableTextas a text and null (or the value of another property?) as its key.This way selects wont always select the first data element and would require the user to pick the correct one. Additionally optional selects would be more easy to implement.
Using a combobox to fake that doesn't feel good because of the input-behavior.
The text was updated successfully, but these errors were encountered: