Need help on Incremental load of VLayout's

[sibasish.palo]

Hi,

Need some help on incremental load of a VLayout

VLayout content;//main layout which holds all child VLayout

i am running a loop to add 30+ child VLayout to the parent layout

for(int i =0; i< area.size(); i++){
content.addMember(area[i]); //area will have all the child layouts
}

while loading the parent layout it takes time to load as it tries to load all child VLayouts at once

Is there any way i can load it incrementally like one by one so that it will not wait un-till all the child layouts are ready to display. or any other technique to accomplish the same.

please let me know if you need more information

please help

Thanks in Advance!!

[Isomorphic]

If you have 30 VLayouts on a single screen, it is very likely that you are using more components than you need to, and you wouldn't have a performance problem if you stopped doing that. We don't have any specifics of what's in these Layouts or what the final result looks like, but if you share more information, we can probably suggest a radically simpler and faster approach.

But as far as avoiding a long delay, you would handle it like any other incremental rendering scenario: render some of the layouts up front, and set a timer to render the rest after a delay.

[sibasish.palo]

Hi,

Thank you for the reply

basically each layout hold a CKeditor and rendering those many CKeditor takes lot of time.

please let me know your thoughts on this

And also even if i render some of the layouts up front, and set a timer to render the rest after a delay. how do i put it into view because the view is already drawn on the UI right??

can you please provide an example, that will be very helpful

Or also is it possible to display the layouts on scroll

to give a idea on the design what i am implementing

Tabpanel

|___VLayout

|____VLayout (holds CKeditor)
|____VLayout (holds CKeditor)
|_____ ............

Thanks!!

[Isomorphic]

We can't help optimize CKEditor of course.

However, adding additional Layouts after the first few have rendered is just a matter of calling addMember().

It's also possible to leave placeholders that are the same size, then replace them with CKEditors.

Another approach would to just render the editable content in a Canvas, with an icon you can click to edit, which then creates a CKEditor on the fly.

Finally, you could use the scrolled() event to add editors on the fly, but this is more challenging, and not clearly better than the above suggestions.

[sibasish.palo]

Thank you for the suggestions

[slick07]

Hi Isomorphic We have a similar situation were we create a view using a list of TileGrids (see attached image). The number of TileGrids is variable depending on the DataSource and for a large number of lists it takes too long to load, obviously.

However, adding additional Layouts after the first few have rendered is just a matter of calling addMember().

How do we know when the first few TileGrids have rendered? On an upper level we are using a "Loading..." message window while loading multiple views (including this one) and hide it when the rendering of them is complete using a code like this:

loadingDialog.show("Loading...");
//load view 1
//load view containing the list of TileGrids
new SmartGwtTimer() {
public void run() {
loadingDialog.hide();
}
}.schedule(0);

We are using that timer because we do not know when the rendering is complete but perhaps there are better solutions? If we start the process of adding the other TileGrids using also a timer then hiding the loading window is still scheduled after and the interface remains locked...

Finally, you could use the scrolled() event to add editors on the fly, but this is more challenging, and not clearly better than the above suggestions.

This is how incremental rendering is implemented for ListGrids?

[Isomorphic]

Drawing is synchronous, and you can just check isDrawn(). Remote data loading is asynchronous, so when a widget such as a ListGrid is configured to load data remotely, when it is drawn that means the headers, etc, exist but the data rows have not drawn yet (or tiles with a TileGrid).

ListGrid incremental rendering indeed works by reacting to scroll events, but it is more sophisticated than just adding additional members, as only the visible range is drawn at any given time (so areas that have scrolled out of view up top are reclaimed).

You can make use of this incremental rendering behavior to implement a very very scalable scrolling view of widgets using recordComponents - example here. This is simpler than implementing your own scroll-based rendering, and certainly simpler than figuring out your own pooling and reclaiming mechanism for widgets that scroll out of view.

[slick07]

OK but the recordComponents mechanism is available just for ListGrid... In our case we are using a list of TileGrids on an horizontal axis. We use TileGrids because of the drag and drop feature for tiles and this is acceptable. The problem appears with the list of TileGrids. I do not see how we could use the recordComponents mechanism for this...

[Isomorphic]

Incremental rendering is built-in for TileGrids, but vertically.

If you had a vertical stack of TileGrid that needs vertical incremental rendering, you could do that with one TileGrid in each ListGrid row, via recordComponents.

If you're implementing incremental rendering horizontally, you'll have to do it yourself - however note that having to scroll horizontally in generally considered something to avoid by UX experts.

[slick07]

I understand. Unfortunately for a Kanban view like the one from the above image it makes no sense from the users point of view to use a vertical scroll for the list of TileGrids(that are also vertical)... So we are on our own for the horizontal scroll. Thank you!