I wish to create a 'master' data table which is formed by linking together, via common identifiers, 5 or more 'sub-tables' so that if I change a sub-table it will automatically update the master. I can easily create a table with all identifiers which can be used as the initial master table as the starting point.
This is similar to the join function within JMP but I want it to happen without my intervention.
Has anyone encountered this type of request before and is there an easy way to enable this type of functionality?
I think this will depend on how the tables will be managed, specifically via scripts versus interactively in JMP.
JMP now supports a reasonably functional event model, and objects can subscribe to these events so that actions can be performed when an event is raised.
So you could be working with a table interactively, and when you close it an event gets raised which could be used to trigger updates to other tables.
The key to event handlers is how they are initiated - this has to be done through a script and the script has to know about all the other associated objects (i.e. the ones that react to the event). So you need to think about the problem in a "workflow" context - for example, it is easier if the master table is opened using a script - this then gives an opportunity to build the event handling wrappers before handing over to the user for interactive use. Having said that it is als possible to attach a script to a data table so that it runs as soon as the table is opened.
At a practical level I've never dealt problems where I have had to build complex event subscriptions. The simplest use-case that I deal with in almost all the code I write is this:
1. Open a data table
2. Create some interactive report windows, with an event handler (often creating hidden sub-grouped tables).
3. When the user closes the report window respond the the close window event - zap all the intermediate hidden tables and close the main data table i.e. do some nice housekeeping.
Within the scope of the JMP functionality, these things are not difficult to implement. As I said, the hardest part is being clear on the use-case / workflow types aspects of the problem.