Do you want to see SAPUI5 Smart Controls (sap.ui.comp library) as part of OpenUI5? If yes, I’d be glad to hear your opinion on that. We had already enquiries via different channels (e.g. github). As this is huge undertaking and we have lots of open questions I’d be glad if you could share your experience and opinion on following questions:
Am I missing something in the list above? Please, add it in the comments. You can also check out this post for a bit more context.
Smart controls are very powerful controls.
It would be great if we get this in OpenUI5.
Use case: Define what you need, it will be rendered automatically, In Most of cases we have to provide same functionality with different entity at different place. So this will save us lots of time.
Value Help dialog, Filter Bar, Smart Table are the controls which we have used mostly.
Only Odata protocols.
Thanks @rbhuva for the details. Did you have the need to 'attach' other controls to OData? For example, something that was not part of smart controls offering and you needed OData annotations logic only. So you do you custom 'assembly' OData+control. A bit weird question, but just exploring the use-cases boundaries...
It's a great decision to bring the SAPUI5 Smart Controls to the OpenUI5. Generally, it would be great to move all of them to the OpenUI5 unless it's not blocked by the third-party modules' license used in Smart Controls.
> What are the typical use cases when you use smart controls?
Data representation and work with data: review, search, filtering, analyzing.
> Which are the controls you use most from the library?
Tables, data grids, export to Excel, value help.
Generally, when working with data grids/tables, one of the most critical feature is export grid/table data to the Excel file (.xslx), not just CSV.
> Any control’s functionality in particular, that you find helpful?
Export to Excel, search, filtering, value help
> Apart from OData, do you have other backend protocols that you use?
No, the data exchange is powered by the REST.
> Does it make sense that the complete library is moved into OpenUI5? Are all parts needed?
To simplify the future maintenance process, I think it would be easier to unify the codebase of SAPUI5 and OpenUI5 as much as possible. And let a developer decide which components to use. On the contrary, the more customization is done, the more expensive, bug prone, and laborious maintenance will be.
Thanks for hearing the feedback and extending the OpenUI5.
I try to use the Smart Table and periphery any time I need to produce a work list and I can't use straight Elements, usually due to the nature of the app or the back end of my customer. Sometimes that works with annotations, other times I construct the standard columns and filter fields manually.
My main goal is to avoid having to code all the logic for filtering and sorting. Where possible, I also try to avoid doing search helps.
Any control’s functionality in particular, that you find helpful?
OpenUI5 applications currently cannot really follow the Fiori design guidelines because SAPUI5 controls aren't available. In the guideline section Selecting a Single Value or Option, for example, it is recommended to use "Input field with suggestions and Value Help Dialog" depending on the number of selectable options.
Due to the missing Value Help Dialog, OpenUI5 app developers tend to use e.g. sap.m.ComboBox (as reported in issue #927 and #3129) which is, however, not designed to hold more than 100 or 200 entries.
OpenUI5 applications currently cannot really follow the Fiori design guidelines because SAPUI5 controls aren't available.
If there are no any legal (license) limitations, then ideally and at the same time the easiest way would be just publish SAPUI5 "as is" under the opensource license and rebrand it to "SAP UI5", completely abandoning the OpenUI5 brand, which always leads to confusion (SAP SAPUI5 vs. SAP UI5 vs. SAP OpenUI5). Users then could benefit from the whole power of the framework and the UI5 team can save a lot efforts on maintaining two codebases. While for the paid users there should be provided some extra features on the backend.
most of the OpenUI5 use cases are not exactly Fiori or at least not targeted to be Fiori compliant.
@vvelinov, as far as I get, SAP Fiori is a set of recommended UX guidelines to be followed to achieve the optimal UX using the UI5 framework and which exactly version SAPUI5 or OpenUI5 is used doesn't play a role, isn't? If I get it correctly, the distinguishing between both of versions is a matter of legal issues, rather than UX.
In addition to Mike's reply, but also regardless of any UX guidelines, OpenUI5 is currently technically limited in a way that forces app developers to either create a notepad control or define a fragment, reusing sap.ui.table.Table like the Value Help Dialog does, if the number of selectable options in Input's value help is huge (e.g. 1000+).
An existing Value Help Dialog in OpenUI5 would help applications reducing the TCO.
it would be very nice if the smart controls where openUI5. If you develop UI5 private with CAP where you get OData Service it would be real nice.
I Like the smart table a lot, the whole sorting / filtering / personalization. Swagger / Open API Support would be nice.
Support for custom personalization service URL would be really nice.
Best regards Richard Brünning
First of i just want to say thank you! This is one of the best things that could happen for UI5.
The most common use case for me, is when users need to be empowered to slice and dice in a data set and displaying, sorting, filtering as they wish. To be able to create complex views and store them as variants for them to reuse. Pre-Smart Controls we often had to create multiple pages/tables in order to give them these options.
Beside that, working with CAP just makes it so natural to use Smart Controls, since a lot of the backend/service code you do, becomes reusable and easy extendable.
Most used controls are SmartFields, SmartTable, SmartFilter and with that comes Variant Manager,
Since i use oData V4 more and more often, i often find it frustrating that i cant use oData V4 on smart controls (unless it's elements ofcourse). For me this would be a great addition if smart tables was fully oData V4 supported.
I think UI5 would be used a lot more outside of SAP community if it supported graphQL.
@Mikkelj thanks a lot for the shared details. Sounds like variants are valuable to you? So are you using same variants shared amongst all users or mostly user private variants?
How about value help dialog? Do you find it's functionality useful or something is missing for you?
Do I understand correctly that you have the need to use OData V4 outside of what fiori elements offer? Any specific use case here?
Hi all, I'd agree with one open source code base for all of UI5 that simplifies it's maintainance while offering it's distinctive features, including smart controls. Such a move would raise acceptance in the open source community, who would otherwise be wary of inadvertently infringing IP, thus reinforcing it's general perception as an outlying SAP technology with a potentially outdated IP Model. Hence, taken all these factors together, not worth looking at.