I have a table with some data and I have a SubView attached to each row of the table. The SubView is a very simple view with a table in it that receives an ID from the first table and does a sub-query based on whatever row is selected.
One of the values that gets queried in the SubView is a file path, which I want to pass back to the original view so users can preview a file based on the file path. I don’t know what the file path will be until a SubView is expanded and a row is selected in the SubView table.
What is the easiest way to pass a parameter out of a SubView?
How would I then access the bidirectional parameter from the first view (the one that houses the table with SubViews)? Would I create a parameter inside the table->rows->subview->viewParams object?
I spoke with my coworker and created a message handler to pass data from the SubView back to the view.
Create a custom property on the view that houses the table with SubViews.
Deep-select your table, right-click and select Configure Scripts....
Click Add handler... to add a new Message Handler. I named mine getSelectedFilePath and chose a Page scope.
Add this line to the script: self.view.custom.selectedFilePath = payload['selectedFilePath']
Go to the SubView. In my case, I only had a table on that view. Right-click on the table and select Configure Events....
Choose an event handler (like onRowClick). Add this to the event handler: system.perspective.sendMessage('getSelectedFilePath', payload = {'selectedFilePath': self.props.selection.data[0].filePath}).
Every time a row is clicked, a message is sent to another view, which I used to then open a Preview window and pass in the video file path.
I've been using this method, but why is it not possible to use the bidirectional/output parameter to send the data back? It seems to only work with embedded views but not on tables.
Because the row data is passed to a subview in a single parameter. Implementing bidirectionality on this would violate the established design principle that table edits go through an event handler to be processed, and not directly applied to props.data. (And I would expect the implementation to be horrifically complicated in the component, so IA just doesn't want to.)
Edit: Would also break the ability to enforce the edit control settings in props.columns, so probably cannot be implemented.