SDK components – development direction & concepts
This is a blog based on comparison of approaches on how to get an Accordion… it is based on 3 blogs/documents on accordion in Design Studio.
- MANOJ KUMAR‘s post on Accordion Menu in SAP Design Studio
- Mike Howles‘s post on Design Studio SDK – SAPUI5 Accordion Menu
- Karol Kalisz‘s post on Design Studio SDK: (dynamic) Accordion Component
Here I would like to concentrate on the use cases and approaches. I list the points which
1) standard modification vs SDK
many complex controls can be produced by uise of standard content and adjustments via CSS, but my question is – how far should this acrually go. When looking at many posts, not only this example from Manoj (which is by respectable – the way seems to be very advanced and I am sure this was also time consuming), but also some other blogs on various modifications to get a requirement done I ask myself – is this often a requirement to stay on standard content? SDK is not so difficult, simple controls can be created easily – one day development and it is available. What is the reason that it is not followed on? Is there something we can help about from SAP side?
2) dynamic vs static
second point is – there is a nice option to create the advanced properties for SDK components, but what is the requirement of consultants – do you need more the way to definve the content by easy to use properties (very good example given by Michael in his accordion) or do you need something what is more dynamic in use (check out my accordion).
3) technical key vs text
I am coming from the development side, so I always work with technical name and keys (which I like to be unique), Michael has made the Accordion menu based on texts. Question here, how are you working – based on texts (how are you handling then translation) or is it ok to use keys for scripting access?
4) pre-defined vs re-loaded
I have placed the event “onFirstExpand” to allow load of the content when the section gets expanded, this is of course nice when you have bigger data to be processed, but in general – which direction are going your requirements for such components? more static creation and then no updates or dynamic load of content on user change?
5) woks-as-is vs styles
I have started to apply special styles to all content I create in the components, is it clear and usefull to all how this can be used? or you would like more “styled to the end” components which you do not need to touch any more in terms of Ux?
6) properties vs setters
In many cases the property can be made visible in the designer (independent on the place – properties or advanced properties) but the easiest way is to provide scripts, eg. in my Accordion you do not find any option to define the content, but you can make this with scripts. Is this something which is desturbing oyu in the work in designer (eg. the content in designer is always empty)
7) goodies vs basics
I have started to create components with images, which can be set optionally. This is a kind of goodie on top of the standard UI5 content, like in this Accordion case – is this something which can be used in your projects and helps you on the visualization or you would like more to stay on basics to be aligned with common Ux?
these are points of the non-tech nature which I would like to put for discussion. Perhaps this can help us to understand the reasons and use cases of all who are looking into Design Studio SDK.
Looking forward for your view on these topics.