Perspective: Designing a "table" for mobile and PC

To answer my own question, this definitely works and is unbelievably more efficient

I ran this with 10,000 instances with no issues. Granted my view is alot dumber than yours, but the virtualization premise should help yours out too.

DynamicHeight.zip (14.4 KB)

1 Like

I’ll have to have a look at it tomorrow, it’s pretty late down under! Sounds interesting though.
Previously, I was creating the instances array for the flex repeater via a script on change of a session prop, but 649 rows killed the browser. So then I put the flex repeater into its own view and used that in a carousel, when again, I created the views property via script and used an items per page to split it up. The params I pass into the flex repeater views are just elements which make up the tag path to the device (tank) displayed in the rows. The components in the flex repeater views then use that base path to read their tags.
I thought that maybe instead of having the data live, I could just read all the values and return a json document with tag values to then display. These fields don’t technically need to be second-live, I could give them a refresh button. Last resort…

Couple of comments that may help:

When you are in the table you should probably use a dataset. I find that using a dataset instead of a json perspective seems to pass it around more efficiently. Though this may also just be in the designer as it tries to render a massive json array in the properties list.

Could be that once its virtualized in a table, it only tries to "read" the tags that are currently rendered on screen. This would probably allow you to make it real time.

Worst case scenario I would make them at least refresh themselves, put a ticker property on the embedded view that at now(5000) refreshes the data.

I’ve done some testing. I tested the following row View scenarios, all using the carousel container to house my flex repeater View which repeats the row View. Not sure if this image helps to visualise it. Ignore the dodgy grey area and the Sahara of empty space… Also, the embedded Views in the Row Views in the screenshot aren’t actually embedded views as they’re from (3) below, however these would be in (1) and (2):

  1. Row View contains embedded Views for displaying tag values, given a tag path. This was the original View I was using in the above posts. This has the most issues with performance and I cannot display more than 20-25 rows before it starts to crash the browser. It’s also super slow to load the tag values in.

  2. Row View contains embedded Views for displaying values given to it via params. i.e. you supply a value “32” and it will display “32”. These Views do not use tag indirection to read tag values. I populated the values in these by first collating a list of all the tags to display for all of the rows to display them for and then bulk-read the values in a script function and wrote them directly into the params passed into the flex repeater rows. This can handle a few more rows than (1) and load time is a little faster, but still can’t get past around 40-50 rows before it crashes.

  3. Same as (2) except removed all embedded views from the row View and instead just used basic components (Labels and Flex Containers). Using this approach, I could display more than 250 rows, but less than 500. I didn’t test where the cutoff was.

This leads me to believe that embedded Views cause performance issues and should therefore be avoided. However, this is counter-intuitive, as these are equivalent to Templates in Vision which are its lifeblood. Is it possible to improve this?

The last thing I need to try is (3) with tag bindings.

This leads me to believe that we have something configured differently at a high level. I was able to display over 10,000 of my embedded in the table with no issue

I guess I have a few questions:
A. Do you need the carousel in this case? Or was that just an attempt to optimize things
B. For the table is ‘props.virtualized’ True? This is a fundamental necessity here, as it only triggers the screen into rendering the rows you can see, not all of the data in total.
C. If you are virtualized then are you passing the table a dataset with your parameters in it, or a json? The designer hates loading large json arrays
D. Is there a reason that each of those labels is an embedded view? At a high level, not knowing your end goal, this feels unnecessary?
E. Is this on something like a raspberry pi, or a device with a really slow network connection? Or a regular server grade device?

I can wire mine up to some more data and see what happens as well

Sorry I must have missed mentioning it, but this was using a flex repeater view, not the column view. I couldn’t get it to display how I wanted with the column view as I need some components to change text alignment and to span multiple rows… Hang on, I don’t think that is relevant…

I think the penny just dropped. I’m using a flex repeater, you’re using a table. I just read the user manual, and I didn’t realise you can give an embedded view into the table component. I’ll give that a go, awesome!

Re why I’m using embedded views for the value displays. I have some for displaying analogue values which I’ve setup to have the value a particular style and margin with the eng units beside it, also with the correct flex container position property values. I also have one that has a sparkline chart beside it, one that has a percentage beside it as well for things like tank levels, and one for setpoints that includes the eng units. The analogue templates pull the eng unit and format string from the tag. The view for the string values was just to keep it consistent mainly, but it also defines in it the style of the string. Otherwise I have to do this all manually every time (or copy and paste) and if I ever need to change it for some reason, it’s one or a few places, not hundreds. I can also configure specific bindings on the components in the views as well of I need. I do the same thing for Vision projects

Definitely, the ability to virtualize the table will heavily impact the performance. Hopefully that works for you!

1 Like

Hmm, I just tried this, but I’m not seeing any options to use an embedded View instead of a table row.

There’s a sub-view property but that seems to be attached to a table row, it doesn’t replace the look of the row itself.

Create a one column table, where each cell is a json including the parameters you need

Then reference that in your embedded view from params.value

I’m just jumping back onto this and finally found where you were talking about all along RE the viewPath in the column config of the Table. Cool!
However, I’m struggling to pass my 4 params to my view…
I can see that there are view params you can pass that are under table.columns[0].viewParams, however it seems that this applies to every row (i need different params per row).

This is what I have:
image

and this is what i’ve tried in the data for pass the params (SitePath, TankFarm, TankPrefix, TankNumber) - passing just the TankNumber should suffice for testing as the rest are defined with default values:
image

These keys and values within the EmbeddedView object have no impact on what’s displayed.
However, as soon as I add some values into the columns section, all rows are updated with those values:
image

I tried this as well:
image

The user manual is confusing:

Tried adding a ‘value’ key as the user manual says you need for object array elements…
image

Second question: how do I set the height of the rows?

@cmallonee @PGriffith

Got it. I found this in the user manual… not very obvious, also very strange to implement, see the blank “EmbeddedView” object:

image
The reason there’s an empty “EmbeddedView” key is so that it’s associated with the EmbeddedView column… I have no idea what would happen if I wanted to have multiple columns where each one used an embedded view with the same params (and if so, what if those params needed different values??)

and my Embedded View params definitions:
image

I still have no idea how to set the height of the rows though… currently each row is full screen height, or there abouts (very tall!)


(that’s almost a single row, some cut off the bottom)
This is what it’s supposed to be:
image

Adding cells.style.height as per this post ([FEATURE-16567] Perspective Table Row Height - #3 by Paul.Scott) yields straaange results…

So a few things, you can either access view.params.rowData on the embedded view to get all of that rows data, or you can access view.params.value to get just that cells value in that column.

What I do in This case is turn my single column into a json dictionary, so that each “cell” is a whole dictionary worth of data

Make sure that useDefaultViewHeight Is true, and then make the defaultHeight of your view equal to the smallest height you’ll need. If it’s a pain to work on the view at that point while the height is so short, create a binding on the defaultHeight prop that looks at your session.props.deviceType (I think that’s what it is) and see if it’s equal to “designer”. If it is then map it to the tallest height you need, and if it’s not then default to the shortest height

Do you know where that should be defined?

This is on the embedded view itself, and it may be self.view.props.defaultHeight but I would have to look

Whoops I can’t read, thought you said defaultHeight, i thought it was in the table column props, but if it’s not I would have to load up a designer and check. Try just doing the minimum height thing, you may not need the useDefaultViewHeight

Nah there’s nothing to do with height in the column :frowning:
image

There’s nothing to do with height anywhere at all that I can find, in any of the properties :frowning: :frowning: (that was the property that I expected to see, useDefaultViewHeight). It’s weird how in your example you posted the height of the items is ok, but mine is 10 times taller than the default…

Change the actual default height of your embedded view to something like 40 (it will look bad, but see if it fixes it)

I did include a copy of my test here as well, so you may need to grap that and figure out whats not the same

You’re right, it looked terrible haha, but it still didn’t change the height of the rows :frowning:
I had a look at your example to work out how you did the embedded view :slight_smile: i’ll see if there’s anything else in there that’s different, as you say.

I found the issue with Travis’ help. My embedded view was a flex container set to row. You can’t set the height of a row flex, only the width, and some of the components I used don’t “know” their height, so when put into the table they don’t show the height you’re expecting (it sounded more technical coming from Travis’ mouth…)
Anyway, to resolve it (at least for now), I changed the embedded view to column flex, added a row flex container to it where I cut and paste all my content into, and then set the basis of the row flex container to the height I wanted it to be. Then voila, it showed up that height in the Table :slight_smile:

2 Likes

Ahhh, I thought it was a column container. A column container does have an “awareness” of its height in this way as well