Someone having tabs with Seaside html+js cached on localStorage?

Hi Mariano,

Why are you not using css visibility? 

This is what we do: render all tabs and use some easy JS scripts to show() and hide() the html that needs to be shown.

Johan

On 10 Mar 2017, at 15:38, Mariano Martinez Peck <[hidden email]> wrote:

Hi guys,

I have an application which is tabbed based...that is, there is a main menu and each menu item opens a new tab in a "workspace". The user can then go to different tabs. Right now, every single click on a tab, does an ajax request and re-renders the "tab contents area". I hate this approach because even if the tab/component hasn't changed anything, every single tab click is a request + re-rendering. Sometimes the tabs are quite some heavy components which takes some time to render. So the application feels slow even when simply moving around tabs. 

To workaround that I was thinking to cache in localStorage each tabs html and then on each click of the tab, do a html() of the "tab contents area" to the html cached for that tab.

That seemed like a good idea but after start trying to implement it, and I found quite some problems already. The main problem is that <scripts> embedded in the html of the tab. That JS is re-executed when I do:

$(''.workspaceTabContents'').empty().html(localStorage[''tabContents'' + clickedTabId ]);  

And that is bad because each time I click on a tab, the JS is executed again and I have side effects. I could workaround this by stripping the <scripts> out. But then i have other problems.

For example, I use bootstrap-select for my selects. When you do $(''.selectpicker'').selectpicker();   that alters the original HTML. So when you click on another tab and you must saved latest HTML of the currently selected tab, :

localStorage[''tabContents'' + previousActiveTabId ] = $(''.workspaceTabContents'').html();

it is the already modified HTML. Yet it has the JS...so it would duplicate my selects... 

And this is just to begin with....

Another idea I had is to NOT cache on localStorage on client side but on server side. So that is, if a user clicks on a tab and does the ajax request, I do not re-render the component in Seaside (avoid all cost of #renderContentOn: etc) but instead  answered a cached HTML+JS.  Of course, here I still pay request, network, etc, but at least I avoid HTML generation. 

So I wonder...has anyone ever did something like this? Note that at the moment I cannot afford going with a client-side UI like angular or whatever. 

Thanks in advance, 

--

Mariano
http://marianopeck.wordpress.com

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 10 Mar 2017, at 16:34, Mariano Martinez Peck <[hidden email]> wrote:

I haven't thought about that one. Seems like a good idea. Let me ask...when you need to open a new tab (say a main menu button was clicked), how do you avoid having to re-render all the "workspace" (all tabs) ?  Do you only render the new one and do an append() or something?

The easiest is when you _can_ render all tabs at once, but if that gets to heavy (as Esteban is mentioning), you should do it lazily, which means doing ajax requests when necessary.

I cannot really copy/paste any code for this, but let me try to outline what I would do:

- Each of the tabs should be Seaside components, nested inside a ‘window’ component that holds onto all the tabs.

- When you render the page, the ‘window’ component renders the open tab and does not render anything for the others.

- The tab controls are implemented using javascript and when you click a new tab, this code checks if the tab is on the page and if it’s not it asks the server to render it via an ajax request and appends the generated html to the page in the correct location, followed by a hide() and show().

- One way we do this is generate <div> elements with a unique id that identifies the tab component. If the div is empty, we launch a callback with the id as an argument and our Seaside component then knows which component to render. That just requires you to keep a dictionary of components in the ‘window’ component with mappings id -> tab component.

So… basically what you already had in mind, but using the DOM as the place to store the tab html instead of somewhere else.

My guess is that the hardest problem is to know when you need to rerender a tab’s html (based on changes on the server…) instead of just showing the content already on the page.

Johan

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside