Closed ThePlenkov closed 8 years ago
As I see we can use vInsert = 0 parameter for the flush method. However it's not recommended to be called directly.
Render method just ignores it
Hi,
The render manager's flush function normally gets called automatically during a rerendering. Globally using append will be very problematic. Do you want to use this in a single control? Then changing the renderer to call the write method at the correct place is the way to go. Or are you creating a new render manager yourself? For prepending a list you could iterate over the items in a reverse order in the renderer.
Best regard, Tobias
Hi Tobias,
I'm glad to have your reply.
Look - in fact there is a certain control I have to create: this is a chat dialog window.
In this chat dialog every new message should be appended to the end(bottom). We had a problem with rendering issue ( all list items( messages ) were rerender every single update ). That's why we decided to use own rendering over Rm.renderControl function.
However now we have a new requirement.
We need to implement treshhold in the opposite way. We always scroll from the bottom to the top to see previous messages.
Standard functionality supports only top to bottom scenario.
This problem can be easily solved just by adding a special parameter to the RenderControl function to say render manager that we need to insert it in the beginning.
This will not brake the current logoc as this parameter will stay by default as append.
I wonder why SAP didn't do this yet.
As I see Fiori 2.0 concept provides chat option. All modern messengers including iOs have the same guideline with input field and the last message in the bottom.
When scrolling up the app loads history and renders the content in the top. The easiest way I see how to do this is to use prepend function. We'll just insert every previous message in the beggining extending the list.
Are you looking for something like this? https://openui5.hana.ondemand.com/explored.html#/sample/sap.m.sample.ListGrowingUpwards/preview
Wow! I see it's already in 1.40. Thanks
However if the library does this every time rerendering the list entirely ( and when using Item Factory it does every time) just by appending items to the end in every treshhold change - that's not good also.
When having a long list of messages - let's say thousand.. They don't take much memory for keeping all of them. Every single scroll will fire a new rerendering process for the whole list.
That significantly decreases the overall performance.
I created previously an issue about this but it was rejected: https://github.com/SAP/openui5/issues/1097
Meanwhile - what we expect from prepend feature is more than list treshhold.
It can be used in different layouts giving us opportunity to add elements from the start and the end of the container without using reverse flex option.
What's more intersting - it's already in!
jQuery has prepend. Flush has the parameter.
What's needed is just to enhance render method with it.
We really wish to have this feature.
Thanks!
Petr.
@ThePlenkov can u refer me a jsbin that shows "factory" forces growing list to rerender from scratch.
@aborjinik Do you mean sap.m.GrowingList or just List?
We use an own control that is inherited from sap.m.List. sap.m.Growing list is depreciated and we didn't even try to use it.
We use FeedListItem where items aggreagtion is defined like "{ path: path, factory: .factory}"
However it doesn't matter which control.. As this is list is a type of ManagedObject - we have this part of code run every time: ![Uploading image.png…]() https://cloud.githubusercontent.com/assets/6381507/17481943/28da33b0-5d88-11e6-84c4-acce9d99439e.png
As you can see - every single JSONupdate triggers the whole list rerendering including all items in the case when factory is used.
I will try to find the time to reproduce the case in the public project.
Best regards,
Petr
@ThePlenkov i am talking about the growing property of the sap.m.List.
It actually matters. FOL, what u need is already available in the framework with growing=true and growingDirection="Upwards". Also growing property enables the extended change detection of the list binding which creates "diff" from the binding updates. Since growing overwrites the default ManagedObject#updateAggregation method, it only deletes or inserts necessary items and does not rerender the list completely
Because of the compatibility reasons ManagedObject#enableExtendedChangeDetection is private at the moment and only implemented for growing list.
@aborjinik Wow! That's a new thing for me. Could you please describe which version is it available from?
Thanks!
Petr,
I mean not only upwards - it's 1.40 as I understand. I mean updateAggreagation redefined function for growing list. We have 1.38 and as we see 1.40 is not yet stable one and out of maintenance:
growing feature was always supporting extended change detection of the binding. ~ so probably since 1.16.
Dear developers,
Here is the new feature I would like to suggest you to implement.
As we all know renderManager is a very base object that is rendering almost everything in UI5.
In fact what it does it finally calls jQuery.append() function ot .html(). Thus, when rendering a line ite into the list it always appending into the end.
Now we speak about an option to revert the order and to insert it not to the end end but to the beginning.
In this case jQuery.prepend() function is what we actually need. However currently it's not possible to do. We have to rerender the whole list again.
If we extend the chain .render() -> .flush() -> .()_fPutIntoDom() with new parameter bPrepend for example we can handle not just appending but prepending as well.
Best regards,
Petr.