[Seaside] Multiple tabs with their own root components

[Karsten Kusche]

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 (emaringolo at gmail.com<mailto:emaringolo at gmail.com>) 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
seaside at lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20200811/96d077a9/attachment.html>