sap.m.IconTabBar doesn't support PreserveContent functionality

[sap]

sap.m.IconTabBar doesn't support PreserveContent functionality

[Michadelic]

Dear cmastandrea,

we will have a look at this issue and get back to you.

On a side-node. It would be a lot easier to just use our UI-Controls (e.g. sap.m.Input) inside the Container Content instead of creating your own DOM-Nodes and adding these to the control tree.

Cheers,
Michael

[trevornc]

Hi Michael,

The use of the HTML input field was just for demonstration purposes. I agree that where possible it would be beneficial to use the sap.ui.Controls, however, there may be situations where either a required control is not available as part of OpenUI5 or we may want to embed other non-OpenUI5 content. For example, flash content or perhaps content that is already written in a different framework. This last point is a significant issue for products that may already be in production written in other technologies that need to be slowly integrated into the OpenUI5 architecture.

Irrespective of the above, it seems odd that the preserve content option is provided for the TabStrip but not the IconTabBar.

Thank you for the quick response,
Trevor

[akudev]

Hi,
this looks like a bug in the IconTabBar: in setSelectedItem it deletes the content DOM ($content.empty()) without giving the RenderManager any opportunity to preserve plain HTML stuff.
We should either rely on the subsequent rendering to clear the content or manually trigger preservation.

Usage of plain DOM nodes in the example was perfectly fine and is actually the point of the issue. However, the way how the preserve area is used and manually the "data-sap-ui-preserve" atribute is set on the added DOM nodes looks wrong to me. This is not how the HTML control is supposed to be used. This attribute is used internally by the HTML preservation mechanism.
The HTML control is supposed to be used by setting some HTML content and optionally modifying this content in any way. The control then takes care of preserving this HTML content.
All our examples should be done like this - have you seen one that acts like your example code?

Maybe it's a workaround for the fact that the third HTML is only added to the DOM when the third tab is activated, but still this is not supported. Rather react to the events of the tab container controls.

Nevertheless, the issue also occurs with "regular" usage of the HTM control: http://jsbin.com/gaca/49/edit

Regards
Andreas

[trevornc]

Hi Andreas,

My sample was modelled on the qunit test that is contained in the SDK, sap.ui.core.qunit.HTMLinGWT.qunit.html.

I did not see any other examples (not that I looked after finding the unit test) that demonstrated this feature. As I mentioned, some updates to the documentation and an example would be useful.

As a side note, perhaps you could explain why the IconTabBar and TabStrip remove the DOM content and don't just hide it using CSS ? I am not implying this approach is incorrect I am just trying to understand the reasoning. Interestingly, the sap.ui.ux3.NavigationBar does not remove the DOM content, so the behavior seems inconsistent.

Regards,
Trevor

[akudev]

Hi Trevor,

well, there is the official HTML control documentation (example page) which should be the first place to consult:
https://openui5.hana.ondemand.com/#test-resources/sap/ui/core/demokit/HTML.html
So even though there are for sure underdocumented areas, there is obviously a way to see how the HTML control is used.

Unit tests may access internals which should not be used by applications. And if you fond the hidden unit test, you could have also found another TML control test page:
https://openui5.hana.ondemand.com/test-resources/sap/ui/core/HTMLControl.html

you could explain why the IconTabBar and TabStrip remove the DOM content and don't just hide it using CSS ?

If invisible content would be all left in DOM, the DOM could grow drastically. There are application suites like Business ByDesign and Fiori which have many different sub application with different pages and views and tabs and... so usually invisible content is not in the DOM. Keeping the DOM small is also very important for the weaker mobile devices. Just increasing the number of DOM nodes can make certain iPad versions freak out.
Sure, for a small app this would not be an issue and maybe the IconTabBar could also have done without deleting DOM, but it's hard to make a generic UI control perfect for every usage scenario.

The NavigationBar does not have any content area. If you mean the ux3.Shell: it indeed acts differently, it leaves the handling of the content entirely to the application. This is because many use-cases actually want the same content, but want to filter it or modify it somehow. Or they want to add animations between the different content blocks. So for this root-level control we wanted to leave max flexibility (and some effort overhead) to the app.

Regards
Andreas

[trevornc]

Andreas,

I had already found the HTML control doc and the TML test page, however neither of those (or those for TabStrip or IconTabBar) mention/link to the ability to the preserve content functionality. The qunit test was the only place that I found that used this preserve content functionality provided by the render manager.

I had guessed that the reason for removing DOM elements was to keep its size small, however obviously there is an overhead in the extra DOM manipulation that has to occur to remove and replace elements. Also, with the preserve content option that you provide, the content remains in the DOM, just in a different location. If anything this is the worst of both worlds as you end up with the same size DOM but incur the added overhead of moving things around.

I don't want to move too far off topic from the original problem but perhaps having an option on IconTabFilter (and TabStrip) that controls the behavior of the DOM content, such as REMOVE or HIDE allowing the developer the option of choosing the most appropriate option.

Thanks again.

Regards,
Trevor

[akudev]

The "preserve content" functionality is purely internal. Nothing that should be used directly. It only works behind the scenes and makes sure that custom content of HTML controls survives re-renderings.
You only need to know that you can put any HTML into the HTML control and you can manipulate it.

the content remains in the DOM

No, in general it does not. The HTML control is a very special case where this is true. But for most/all other controls only the JS instances remain alive.

Option to remove or hide would be an idea, but: what is the benefit? (remember this option also causes an increase of code size, so it should be justified) You want to rely on the HTML being always there for all tabs? This would mean an initial rendering overhead to create the content of all tabs instead of only the first visible one. And lazily creating content but THEN keeping it in DOM means you again cannot rely on it to exist.

Regards
Andreas

[trevornc]

Andreas,

Thank you so much for your responses.

I believe that the reason why I used the "preserve content" functionality was that all my experience was with the sap.m.IconTabBar for which the preferDOM option was broken. I now realize that setting preferDom to true (which is the default) should automatically preserve the content. Sorry it took so long for me to grasp that ... I have updated my jsbin sample http://jsbin.com/gaca/51/ so that it no longer uses the internal functionality and I can see that the TabStrip behaves as expected.

I guess my reasoning behind allowing content to be hidden rather than removed is based on the assumption that the web application would be running on a Desktop connected to a relatively fast internet connection. If I look at it from the perspective of running on a mobile device with a slower connection and less memory then loading all pages (even those not viewed) does not make sense.

Now I see how the HTML control was supposed to work with the sap.m.IconTabBar I see less reason to hide the content.

Thanks for being willing to discuss this with me and I look forward to the fix.

Regards,
Trevor

[Michadelic]

Hi Trevor,

thank you for reporting this.I fixed the issue in our master branch.
It will be available with the next OpenUI5 patch 1.18.11 which will be available beginning of April.

Have a great weekend!
Michael

[trevornc]

Hi Michael,

Thank you for the quick response to this problem.

Regards,
Trevor

[akudev]

Hm... looks like this patch did not make 1.18.11. Michael, could you please check?

[Michadelic]

Hello Trevor,

sorry, Andres was right, the change did not make it in 1.18.11
It will be part of the 1.18.12 delivery which is scheduled for Monday next week.

Sorry for any inconvenience and have a great day!

Kind Regards,
Michael