[Seaside] Multiple tabs with their own root components

[Esteban Maringolo]

Hi Karsten,

> The only requirement for that to work is that you implement updateStates „the right way“.

The snapshots and the updateStates: (or the proper answering of
#states of objects to be backtracked) is what I always understood that
was needed.

I should double-check whether I'm doing it correctly (which I probably don't).

> 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.

Only the session is shared, and in this case everything is read only,
so no issues in this case.

I have another app where the application model can't handle different
tabs and I need to forbid opening a new tab, but that's another story
:-)

> If only your components store all the state, it may work.

The store the UI state, the model is at the "model" layer, but there
is no "Component-Model", just components and the domain models.

> 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 <karsten at heeg.de> 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 (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