[Seaside] Multiple tabs with their own root components

[Bob Nemec]

 On the point...
    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.
...we have that issue with our in-house ERP system (about 650 users). Having users open an internal application link in a new tab is just wrong in Seaside.To prevent that we check the history.length on the render for logged-in sessions.We also have options to open the application for saved links that open a domain object.That also had to to be checked for. To distinguish between browser tabs I use sessionStorage.
aSession validNewSession ifTrue: [    html script: 'sessionStorage.setItem("validSession",1)'
    ...]

...if the session is not a special case, and for the next render, I use...
html script: ((JSStream on: '(history.length > 1) || (sessionStorage.getItem("validSession") == 1) ')  then: (html jQuery ajax script: [:script |  script << (html jQuery id: 'user application div') show; << (html jQuery id: 'invalid session message div') hide] ) else: (html jQuery ajax script: [:script |  script << (html jQuery id: 'user application div') hide; << (html jQuery id: 'invalid session message div') show]))].

Users are able to open new tabs with logged in sessions. We provide that with a 'new session' anchor...
html popupAnchor url: (self session requestContext request url printString, '&newSession'); with: [...]
...our WAApplication subclass handleFiltered: checks for newSession and sets up a new logged in session. 
handleNewSession: aRequestContext
 | newSession oldSession companyOop | 
 oldSession := self sessionForRequest: aRequestContext. oldSession isNil ifTrue: [ ^super handleFiltered: aRequestContext].        ...copy stuff from old session to new session...
        ^self handle: aRequestContext registering: newSession.



I'm sure there are cleaner ways to do this (I'd like to see other techniques), but this works for us.
Running Seaside 3.2 on GemStone 3.4.3 Bob Nemec
    On Monday, August 10, 2020, 10:38:18 p.m. EDT, Esteban Maringolo <emaringolo at gmail.com> wrote:  
 
 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/cf82ff0f/attachment.html>