Is there something like Vision Client Tags in Perspective?

[Jay_L]

As is known to all, the Vision Client Tags allow users from different vision clients to operate without being affacted by the others,
while if we wanna achieve the same goal in Perspective which is to let the users operate their own stuff individually,
how can I make it?
Is there any function which can work as a substitute of the Vision Client Tags?

[lrose]

Custom session properties will allow you to store values unique to each session but persistent across views, browser tabs, and other parts of a session.

https://docs.inductiveautomation.com/display/DOC81/Session+Properties

[Jay_L]

Thank you so much my friend!

[salbrechtsen]

Wanted to bump this thread and ask if anyone has found a good solution to this. I would like to mimic the client tag behavior.

What I'm planning to do is have a "pageSessions" object in session.custom. When Session Event Page Startup runs it will check to see if the vars have been initialized, if they haven't it will assign a key to the object being the pageId retrieved from page.props.pageId and initialize the values.

Then I was going to write a shared script or just directly access the properties via bindings.

The way I see it its either this implementation or writing a module and this seems easier...

[michael.flagler]

Session properties are the equivalent to client tags for Perspective. What are they not capable of doing that you're needing accomplished?

[salbrechtsen]

Session properties are shared across browser tabs. I have a use case where a user may want multiple browser tabs open, each with their own set of "session" properties.

So with the solution I suggested the session properties would be segragated by pageId.

I guess the real question I have is what is the lifecycle of a pageId.

[pascal.fragnoud]

Does it NEED to be session properties ?
Maybe you could find another scope to put those properties in.

What's the use case ?

[Felipe_CRM]

From a quick search it seems that pageIDs stay active until the session associated with that tab times out.

Check if a pageID is actually active

No, there's a timeout. Browsers are not required to notify a server of tab closures, and generally don't. I think you are going to have missed notifications if you have to target only one page.

EDIT: the timeout duration is 60 seconds to be exact, at least as of late 2022:

Pages still shown in pageIds key after being closed

Just a note here: closing a page in your browser (or through a script) essentially closes the websocket for that page. On the backend, this registers as a connection loss, and we give the page 60 seconds (by default) to reconnect. During that 60 seconds, the page will still show as part of the session. After the 60 seconds have elapsed, we remove the page from the listings.

See also the following: the pageID is associated with the tab, not a view, which sounds like a good thing in your case.

Dynamically Change/Animate Docked View Handle Icon

What you're hitting here is an unfortunate terminology issue which I see all of the time and which I FULLY understand. the onPageStartup script fires one time when you open Perspective Page in a tab. It does NOT fire every time you perform page navigation. Watch the pageId during the life of your session; the pageId does not change as you navigate between pages because what's really going on is we're just swapping out the View on the back-end and applying any rules from the Page Configuration. …

[salbrechtsen]

I just found this first article as well. I think it will behave exactly how I'm expecting. I'm going to move forward in this direction and I can report back with findings. Thank you!

[salbrechtsen]

No it doesn't have to be in session properties, that just seems like the natural place. I just need a window/tab scoped place to store variables available only to that window/tab.

We sometimes bind UI element properties to the session properties. So the issue we've seen is if we just use plain session properties and have multiple windows/tabs open, changing a session property in one window/tab changes it in all others.

[salbrechtsen]

I'm not saying that the behavior doesn't make sense, I just hadn't thought about session vars being shared between windows/tabs until we started seeing changes in one window/tab affecting all others.

[pascal.fragnoud]

I used to put things in session.customs.
But I grew to dislike this practice, for reasons similar to what you're experiencing.

Put things in the scope they belong to. If they affect a page, put them on the page.
If you need to be able to keep those things from one page to another, maybe you can pass them as parameters. Or use messages to pass them to docks. Things like that.

While it may seem easier to just put properties in session customs, I believe that in the end, proper scoping makes things clearer and simpler.

[Felipe_CRM]

I'll be the first to admit that I can't actually think of a use case where you'd want properties that are specifically tab-scoped that you can't handle with either session-scoped or page-scoped data.

But if there is one, then writing up an extension of the session scope that's limited to a specific tab makes sense to me. If the data truly belongs to the tab rather than to any specific view, then it should be the tab that manages it. Continuing with that train, since the tabs belong to a session, it's not unreasonable to have the session hold on to each tab's data.

Any practical implementation should definitely have some message handlers to make it easy to store and retrieve tab-specific data.

[salbrechtsen]

Yep, what you are saying makes a lot of sense until you need them persisted views which is my use case.

I like the idea of having a dock. That might be a lot cleaner, especially when dealing with bindings!

[salbrechtsen]

What would be nice is if we could have custom props on the page object, as well as the session object.

[pascal.fragnoud]

I haven't (yet) encountered a case where this couldn't be solved by other means. Sometimes it means approaching the structure/design/whatever you call that from a different angle... which is usually not a bad thing. Allows one to weigh the pros and cons, which you can't do when you have only one option.

[salbrechtsen]

Yeah i'm not trying to XY problem myself, i'm looking for other options because what I was going to do felt hacky.

This looks promising

Session properties shared by all pages from the same client

It’s just a workaround, In the onStartup script of your view, add someting like: self.page.props.myProp1 = "myValue" [image] And you can use the value in a binding page.props.myProp1 [image]

I think what i'll do is in my header component either store the props and access them by messages or write to page.props