# Table Embedded View Naming Inconsistencies

**URL:** <https://forum.inductiveautomation.com/t/table-embedded-view-naming-inconsistencies/56990>\
**Category:** Ignition\
**Tags:** perspective\
**Created:** [March 9, 2022, 1:41am UTC](https://forum.inductiveautomation.com/t/table-embedded-view-naming-inconsistencies/56990 "2022-03-09T01:41:09Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![kgamble](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kgamble/32/8019_2.png) [@kgamble](https://forum.inductiveautomation.com/u/kgamble)\
**Post date:** [March 9, 2022, 1:41am UTC](https://forum.inductiveautomation.com/t/table-embedded-view-naming-inconsistencies/56990/1 "2022-03-09T01:41:09Z")

</div>

I just wanted to make this call, as I am not sure its considered a bug, or just weirdly designed naming.

However it is very confusing that based on how you are using an embedded view in a table, it can change the names of the parameters provided to that view.  
For Example:

1. In a column as an embedded view, to access a rows data you use `rowData` and to access the cell value you use `value` (makes sense)
2. In a subview you would access the rows data using `value` (which inherently means you can’t easily use the same setup for a column and a subview, since that keyword is already used for the cell)
3. If you are using the `{style:{}, value:{}}` functionality of the table to change cell/row highlights, in a subview you must now access the rows data with `value.value` and for a column it is `rowData.value`, so if you want to use that functionality you need a third and fourth methodology for getting row data

A great example of why this being the same would be helpful:  
If you have a table that is responsive, and on a larger format you want to show an embedded view as a large column. However on a smaller format you want to turn it into a subview, so that you can save screen real estate. In order to do this, and avoid all of the styling and location areas, you have to create a custom property that analyses `params.rowData` and `params.value` then decides if it should use the `.value` on each of those to decide what the rowData is in the first place. Just to show the data from the row the embedded view is on

I feel like in the case of a subview, the property should just be called `rowData` to mimic the column. However for backwards compatibility sake at this point I could see `rowData` and `value` both doing the same thing. That way you could at least consistently use `rowData` everywhere

In regards to the styling, I feel like it should not pass the object `{style, value}` syntax down into the embedded view, or at least if it does than it should maybe put it somewhere else so that you can always access the `rowData` in a consistent way.

All in all, these have been a nuisance when working on projects with heavy table use that also use a lot of embedded content, especially with the performance issues around binding execution order right now. Having to add in an extra binding just to figure out which parameters you should be using in the first place feels unnecessarily complicated.

Thank you for coming to my TED talk, hopefully there is an easy solution for this in the long term.

TLDR: Table embedded view parameter naming is inconsistent, `rowData` should always come from `rowData`, not `value` for a subview. And the `{style, value}` syntax should not follow all the way down to that `rowData` property.