View startup event not triggering in certain cases

Hello folks,

I’m a bit confused about view startup events. They trigger properly when a page is first loaded, but don’t when navigating to the same page with different url parameters.
example: let’s say I have a view on foo/:param
navigating to /foo/bar will trigger the startup script, but if I try to go to /foo/baz from there, the script won’t re trigger.
I expect this is because the actual view is not reloaded, but I need to find a way around this.

Here’s my use case:
I have a dock that displays things related to devices. I need to pass what device is being displayed on the main page.
So, when navigating to /foo/baz from /foo/bar, I need to update those parameters so the dock know what to look at.

I wanted to avoid using session.custom properties, but do I have an alternative here ?
I there are none, how do I handle multiple tabs opened on different devices ?

version is 8.1.18

You could use messaging and the session scope.

Send messages when navigating to baz / bar and have the main page handle the session scope message.

There’s a problem with this though: It doesn’t work when the user changes the url manually.
Which is why I initially used view startup scripts.

edit: I guess I could put an on change script on the main view parameters ?

A View startup script only executes when the View comes into existence. Changing the URL to pass parameters does not replace the View - it only changes the parameter values. A lot of users think that changing the URL is like loading a new page, but that is only true for multi-page applications, while Perspective is a single-page application. This means that When you load up the Perspective session and are navigating from “page” to “page”, there is no HTTP request being made. Perspective requests information through the websocket, receives this new information on how the page should be rendered, JavaScript manipulates the existing content of the page (and updates the URL to reflect the new configuration - which is what confuses most people), and a user sees the new content. But we haven’t loaded a new WEB page.

The only way to force a View’s startup script is to completely remove the View from the page, and then put the View back onto the page.

Yes that’s what I figured.

But how do I pass my new parameters to the docks ?
Is there a better way than using a change script on the main view parameters to send a message to the dock ?
Would this script trigger on initial page load (is the first parameters assignment considered a value change ?)

Before 8.1.19, your only options were to either use message handlers or session properties because docked view params were static. As part of 8.1.19 we added a new Perspective package function system.perspective.alterDock, which allows for re-configuring all parts of a Docked View at runtime - including the parameters.

The issue is actually finding the trigger for sending the message, not sending it.
I’m guessing the issue would be the same if I had access to alterDock.

I mean:

  • I can’t use a start up script because it just doesn’t work if the view doesn’t change,
  • I can’t use click events because I want it to work when someone enters the url manually,

All I can think of is using an on change script on my main view’s parameters, but that looks a bit ugly to me. So I’m wondering if there’s anything else that I didn’t think of and that I could use as a trigger for sending messages.

I’m curious why you think this looks ugly? I mean, you’re concern here is that the parameters are changing, right?

I don’t think there is another way.

1 Like

I do think a change script on the Primary View’s parameters is the way to go.

I’m not a fan of on change scripts in general, but I guess I’ll walk that road this time.