Introduction
Bookmarks are a very important feature of Design Studio which enable dynamic, self-service applications to be developed. There has certainly been a lot of discussion about the topic on the SCN. The recent post about What’s New Design Studio Feature Pack ASUG Webcast Summary has provided a glimpse of what we might expect with future functionality, so I thought this would be a good time to recap the current bookmarking functionality and present a wish list of desirable features for feedback and further discussion.
Overview of Bookmarks
There are already plenty of posts describing the details of bookmarks and how they work, so here I will just provide a summary of the different bookmark types for context. There are 3 types as follows:
Standard Bookmarks
These allow the entire application state to be saved and are specific to a user.
Fragment Bookmarks
These allow the state of a specific group of components to be saved in an application for a specific user.
Portable Fragment Bookmarks
These are the same as Fragment Bookmarks but can be consumed in other applications ("consumer" applications) by other users (as well as in the original application itself). There are two ways to consume a Portable Fragment Bookmark:
1. Load the Portable Fragment Bookmark in the same application that produced it ("producer" application) or
2. In a consumer application, populate the Portable Fragment Bookmarks (also known as Smart Objects) into a Fragment Gallery component to allow users to select which fragments they wish to view by dragging and dropping onto a Split Cell Container component.
Personally, I prefer to use only Fragment or Portable Fragment Bookmarks as they are much less susceptible to being invalidated as a result of changes to the application UI, unlike Standard Bookmarks which are invalidated as soon as the application is updated.
The Roadmap for Bookmarks
To put the wish list into context, below is a slide of what is planned for future bookmarking functionality:
Source: Figure 14, What’s New Design Studio Feature Pack ASUG Webcast Summary
Bookmark Wish List
Based on my experiences with bookmarks so far, here is my wish list for future functionality:
1. Provide a scripting API for programmatically traversing a bookmark folder tree model
As of Design Studio 1.6 it is possible to retrieve the bookmark folder structure as a tree model using the script API method Bookmark.getBookmarkFoldersTreeModel(). However, this tree model can only be visualised in the Tree component by assigning the model with the setModel() method. The issue with this is that it limits the flexibility of how a bookmark folder structure can be represented from a UI design perspective. It may not always be desirable to show the bookmark folders in a typical hierarchical tree structure as per the Tree component. One alternative representation that comes to mind is a tile-based layout using for example the Fiori-like Launchpad SDK Component from the Design Studio SDK Development Community, in which the user could navigate the bookmark folder structure from higher levels to lower levels by drilling down through groups of tiles representing the level.
To put this into perspective, the tree representation achievable with the current standard functionality is shown below:
Bookmark Folders in Tree Component:
Bookmark Folder Structure in CMC:
Providing a scripting method to traverse the folder structure, similar to the Backend Connection technical component getRootFolders() and getChildren() methods would allow the application designer much more flexibility in terms of customising the UI for navigating the bookmark folder structure.
2. Continue to support Fragment and Portable Fragment Bookmarks in the future "Reworked Bookmark Concept" on the Design Studio Roadmap
Although this may seem obvious, I'm just mentioning it here so as to not take this for granted. Fragment and Portable Fragment Bookmarks are very powerful features which should be retained in the new concept.
3. Allow users other than the creator of a Portable Fragment Bookmark to maintain the bookmark at run-time
Portable Fragment Bookmarks are very useful for centrally authoring fragments so that they can be consumed by end users. One big advantage is that such bookmarks can be centrally maintained such that any updates are automatically reflected in the consuming applications. Here when I talk about "updates", I simply mean changes to the state of the contents of the bookmark made by the author from the producer application, such as filters or UI component state selections, such as a radio button state or a dropdown list selection. At the moment, only the original author of a Portable Fragment Bookmark can update it. When saving a Portable Fragment Bookmark in a producer application, with the Bookmark.PortableFragmentBookmark.saveBookmark() method using the "overwrite" option, if the current user is not the same as the original author of the bookmark then a duplicate bookmark is created. Presumably this is by design.
But why is it important to allow editing by users other than the original bookmark author? I can think of a couple of reasons:
(a) What happens when the original author is no longer responsible for maintaining the bookmarks they have created because they have either moved onto a new role or left the organisation? We now have a situation where Portable Fragment Bookmarks have been potentially consumed by many users, in an Online Composition scenario for instance, with no possibility of centrally updating these bookmarks by the new responsible person;
(b) In a centrally managed scenario, it may be desirable to share the responsibility for updating Portable Fragment Bookmarks across several team members.
Although of course it would not be desirable to allow all users to update a Portable Fragment Bookmark created by another user, I would think this could be implemented by taking advantage of the BI Platform standard security features by assigning appropriate privileges for viewing vs updating within bookmark folders.
Now one response to this particular feature request might be that central maintenance will be supported by the "re-usable component" concept which is also on the roadmap. However, I think there is a difference between the two and a need for both. Re-usable components are for developers to centrally maintain the structure of common application content such as headers and footers at design-time whereas central maintenance of bookmarks relates more to end users updating the settings of bookmark content at run-time in a producer application.
4. Allow Portable Fragment Bookmarks to be consumed in multiple applications without requiring selection from a Fragment Gallery for viewing in a Split Cell Container
In the context of "consumer" applications for the purposes of Portable Fragment Bookmarks, at the moment only an online composition scenario is supported whereby users select such bookmarks from a Fragment Gallery to compose their own layout inside a Split Cell Container. However, I think a legitimate alternative use case instead of this previously mentioned free-style scenario is the scenario whereby multiple consumer applications are required for different purposes whereby they each have a different static part but allow the user to select only ONE Portable Fragment Bookmark for a dynamic part, where the bookmarks available for single selection are presented in a dropdown list for instance, instead of allowing the simultaneous use of multiple fragments from a Fragment Gallery.
This feature would allow for more purpose-built application use cases of Portable Fragment Bookmarks compared to the current free-style online composition approach.
5. Allow re-mapping of bookmark data sources when promoting from one system to another
The planned Reworked Bookmark Concept shown in the slide above includes "Promotion Management support of bookmarks and folders". I am sure this will be a very welcome new feature when introduced in future, especially taking into consideration comments on the need for this in various SCN discussions. Although it may be a given, I'm just including this item here for the sake of completeness in that it is obviously very important to include a mechanism to re-map bookmark data sources, for instance with the Promotion Management Override feature.
6. Allow Technical Components to be included in Fragment and Portable Fragment Bookmarks
At the moment because Fragment and Portable Fragment Bookmarks are defined by wrapping child components inside a container component such as a Panel, as far as I am aware, there is no way to include Technical components in such bookmarks. Given that the slide above shows the new bookmarking concept as being a technical component itself where the included components are selected via the "Bookmark Configuration Selection" property, I hope this will allow selection of both UI and non-UI (technical) components for inclusion in a bookmark.
7. Increase the robustness of bookmarks against internal changes to SDK components that are included in the bookmarks
It is quite common for the inner workings of SDK components to be updated with the release of new versions. Upgrading to a new version of an SDK component should not break bookmarks which include that SDK component. Specifically, the following scenarios come to mind:
i) If a new ZTL function is added to an SDK component, this function should be active in existing bookmarks which contain this component
ii) If an existing ZTL function is updated in an SDK component, the updated version of this function should be active in existing bookmarks which contain the component
iii) If a new property is added to an SDK component, this property should be active in existing bookmarks which contain this component. This is probably supported now to an extent but I'm including it here for good measure.
8. Allow SDK component properties to be flagged as "relevant for bookmarking"
There may be situations whereby certain features of an SDK component require that the values of specific properties should not be captured in a bookmark. For these scenarios it would be useful to include an appropriate flag in the contribution.xml file definition of the relevant properties.
Conclusion
These are my ideas of desirable features for future versions of the bookmarking functionality. I welcome and encourage comments and suggestions from you about the above features as well as other features which would be useful based on your experiences.
Blog Series Index: Design Studio Innovation Series - Welcome
- SAP Managed Tags:
