What is the best practice for letting users click on tables to direct them to pages with relevant data from the row in that table which they clicked on?
Do you have a mouse up event and then run a script to detect the selected row?
Or would the event happen before the select has occurred?
I am going to test it, but I thought if someone has done this, they might have pointers or tips on pitfalls and best practices.
The first element each row has a link as well.
That is a first for me to see as well, at least a first to see through the lens of design.
Background
I thought that in a software I see used, I don't want to name that software, there is a function where the users can click a row in a table and that will take them to a page of data related.
I think the table component that software uses is kind of similar to Ignition, and I wanted to make that functionality in my Ignition project.
The easiest way is probably with a click event on the table. The event object passed to that function should have a row property if I remember correctly.
From there, all you have to do is navigate to a page/view or open a popup, and pass them the data you want.
@zacharyw.larson,
You have a nice "selection" object in the table props where you'll find everything you need (selectedColumn, selectedRow, the dataset in json format, etc.)
One of the beauty of Ignition, is that you build the component you need and the reuse it. You're not tied to a component, designed by someone, with limited features (or at least features that the developper wanted to develop). Et même, une fois qu'il vous plait, vous pouvez le partager sur eXchange!
BTW, I'm interested in knowing the software package you are talking about. Good to know what's good and what's wrong
It isn't a matter of being wrong or right. It is more a matter of monthly fees vs Ignition's one-time fees.
There are many packages that companies can use to implement features like dispatching or scheduling.
If we can use just Ignition though, I think that is best.
I want to change the url and push the parameters though, not the view. Well at least I think I do.
Maybe it is best to not change the URL, but then I think some users might be confused about where they actually are.
Changes views correctly, but the table receives a string instead of a datetime.
If I try to use system.date.parse() I get an unable to parse with "1666263180803"
If I use theDate as a datetime instead of a string, the table again doesn't populate.
Don't use string-formatting of a date for anything other than presentation.
The types you pass into most things in Perspective must be JSON-representable. Dates directly happen to not work here. The lossless form of a java.util.Date object is the epoch-millis it contains. Use system.date.toMillis() and system.date.fromMillis() to convert back and forth between a true Date object and the long-integer milliseconds.
There is no way to keep the URL without the parameters though?
Can I get an example of a multi parameter URL?
I don't understand this:
# Navigating to a perspective page with url parameters.
system.perspective.navigate(url='http://<GatewayIP>:<port>/data/perspective/client/<projectName>/view?key=8')
If I don't change the URL, the performance page on my gateway shows teal from top to bottom for waiting memory.
I am not sure if it means anything bad, but it doesn't look good for sure.
I don't like popup views, and the page I show is best shown full screen.
I might open a new tab instead of just change the URL, but I am not sure yet. I really like the back and forward buttons on the mouse working with the address.
Would you show me an example of a multi parameter URL?
Or could you breakdown that last bit about the view?key=8')
I am not really sure how it works.
I thought maybe for me it would be like /devzl7?which=test?when=date