Multiple tabs with their own root components

Wallstraße 22
06366 Köthen

Tel.: 03496/214328
FAX: 03496/214712
Amtsgericht Dortmund HRA 12812

Am 11. August 2020 um 04:38:21, Esteban Maringolo ([hidden email]) schrieb:

Hi all,

I have a question that I cannot answer myself even though I have built
a handful of medium sized applications with Seaside. To some degree it
is embarrassing, but I need to ask just in case I've been missing
something trivial all these years.

I'm building a "public" web app, and I have some newer concerns I
didn't have before because most apps ran in private environments or
behind logins and were mostly complex UI or flows where Seaside shines
and no one cares (mostly) about URLs.

These days it is very common that you can open a link in a new tab to
view something, then close it, duplicate it or even the browser might
restart on that page. The problem is that with Seaside, as long as one
action continuation is triggered then as soon as you reload one of
these tabs it shows content from the last tab that had some
continuation activated.

My solution was to change all callbacks that do simple #show: actions
with the canonical url of the called page, to implement
#initialRequest: to handle the few cases where I need to provide a
stable url (for sharing and for Open Graph and friends) and to use
Cookie based session tracking.

This is similar to the method proposed years ago by Ramon on his blog
[1], but without meddling with the Render Loop. I guess that the
Seaside book website does something similar.

Is there any other way of achieving independent flow in each tab, each
with its own renderloop with a different root component? So basically
I can have different branches of "_k" when needed.

Maybe a Stateful framework such as Seaside is overkill for these
cases, in particular because it's heretical in many aspects, but I'm
still very productive with its component based development and it's
canvas way of building them.

Shall we start thinking what we need and want for Seaside 4.0? :-)

Regards,

[1] http://onsmalltalk.com/clean-urls-in-seaside

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

> But on the other hand you end up with the same instance of a WAComponent 
> being used with 3 different tabs and then 3 different sets of instance variable values. 

Is that how the snapshot works? I thought it made copies of the 
objects, but not a swapping of the instVars of the registered ones. 

Thanks! 

Esteban A. Maringolo 


On Tue, Aug 11, 2020 at 2:22 AM Karsten Kusche <[hidden email]> wrote: 
> 
> Hi Esteban, 
> 
> isn’t that what Seaside does automatically? You have an action continuation that handles your callbacks and then does a redirect to the render continuation. Then you can reload the render continuation again and again and everything should behave as expected. 
> 
> The only requirement for that to work is that you implement updateStates „the right way“. 
> 
> At least that’s as far as the Seaside part of the game is concerned. If the underlying model can handle all that is another question. If only your components store all the state, it may work. But on the other hand you end up with the same instance of a WAComponent being used with 3 different tabs and then 3 different sets of instance variable values. 
> 
> As an example you can use the simple Counter example, it should behave correctly, no matter how many tabs you spawn and what you do in each of these. 
> 
> Kind Regards 
> Karsten 
> 
> 
> — 
> 
> Georg Heeg eK 
> 
> Wallstraße 22 
> 06366 Köthen 
> 
> Tel.: 03496/214328 
> FAX: 03496/214712 
> Amtsgericht Dortmund HRA 12812 
> 
> 
> 
> Am 11. August 2020 um 04:38:21, Esteban Maringolo ([hidden email]) schrieb: 
> 
> Hi all, 
> 
> I have a question that I cannot answer myself even though I have built 
> a handful of medium sized applications with Seaside. To some degree it 
> is embarrassing, but I need to ask just in case I've been missing 
> something trivial all these years. 
> 
> I'm building a "public" web app, and I have some newer concerns I 
> didn't have before because most apps ran in private environments or 
> behind logins and were mostly complex UI or flows where Seaside shines 
> and no one cares (mostly) about URLs. 
> 
> These days it is very common that you can open a link in a new tab to 
> view something, then close it, duplicate it or even the browser might 
> restart on that page. The problem is that with Seaside, as long as one 
> action continuation is triggered then as soon as you reload one of 
> these tabs it shows content from the last tab that had some 
> continuation activated. 
> 
> My solution was to change all callbacks that do simple #show: actions 
> with the canonical url of the called page, to implement 
> #initialRequest: to handle the few cases where I need to provide a 
> stable url (for sharing and for Open Graph and friends) and to use 
> Cookie based session tracking. 
> 
> This is similar to the method proposed years ago by Ramon on his blog 
> [1], but without meddling with the Render Loop. I guess that the 
> Seaside book website does something similar. 
> 
> Is there any other way of achieving independent flow in each tab, each 
> with its own renderloop with a different root component? So basically 
> I can have different branches of "_k" when needed. 
> 
> Maybe a Stateful framework such as Seaside is overkill for these 
> cases, in particular because it's heretical in many aspects, but I'm 
> still very productive with its component based development and it's 
> canvas way of building them. 
> 
> Shall we start thinking what we need and want for Seaside 4.0? :-) 
> 
> Regards, 
> 
> [1] http://onsmalltalk.com/clean-urls-in-seaside 
> 
> Esteban A. Maringolo 
> _______________________________________________ 
> seaside mailing list 
> [hidden email] 
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside