Example Usage: RawDataView

@log(logger=logger)
def _apply_filter(self, data_filter, channel_data):
   try:
      filter_data_args = (channel_data,)
      self.global_signal.emit('MetaFilter', data_filter, 'filter_data', filter_data_args, 'update_plot_data', ())
      return self.plot_data  # Assuming the plot_data is updated by the filter
   except Exception as e:
      self.logger.error(f"Unable to filter data with {data_filter}: {repr(e)}")
      return channel_data  # Return unfiltered data if the filter fails

Detailed Explanation

This function in a specific view, needs to edit the “selected” plugin settings.

  1. User Interaction: The user interacts with a dropdown menu in the RawDataControls widget located within the RawDataView. This dropdown menu allows the user to select a PluginKey which uniquely identifies a plugin.

  2. Data Fetching: The RawDataControls widget reads a JSON file to fetch current plugins’ metadata, including metaclass and pluginKey (identifying which plugin the user wishes to manipulate).

  3. Signal Emission: Upon selection and info button activation within the RawDataControls, a signal is emitted. This signal triggers the data_plugin_controller_signal within RawDataView. The purpose of this signal is to initiate the plugin editing process via a dedicated function edit_plugin_settings.

  4. Function Invocation: The edit_plugin_settings function is called. This function is designed to manage the editing of plugin settings effectively and is structured following abbr: MVC (Model-View-Controller) principles:

    • Model: Handles data manipulation and business logic -> get,set,unregister,etc

    • View: Manages the presentation and user interaction layer -> Edit Settings

    • Controller: Acts as an intermediary, coordinating actions between the model and the view.

  5. View Interaction: The editing interface for the plugin settings is handled within the abbr: DPView (DataPluginView). This approach prevents the unnecessary spread of data across components that do not require direct access to it, ensuring that each plugin’s settings are isolated and managed within a controlled environment.

  6. Data Update and Signal Processing: Post interaction in the DPView, methods are executed to update the plugins based on the changes made. These updates are propagated back to the system, ensuring all components that depend on these plugins are aware of the new settings.

Note

It would not be possible to use the global signal to perform this action:

  1. Using a global signal for specific plugin settings adjustments is inefficient as it involves complex routing that doesn’t terminate at the DPController but extends to individual plugin instances.

  2. The data_plugin_controller_signal offers a streamlined pathway for direct communication with the DPController, enabling:

    • Direct Action Execution: Immediate effect on plugin settings without traversing through multiple (without this signal, single signals would have to be scaled up to the MainController, then access the DPController) and specific signals depending on the particular instance to be affected/data retrieved.

    • Optional Return Handling: The signal supports an optional return function, enhancing flexibility by allowing operations that do not require post-execution feedback (edit plugins does not need to trigger another action in the view, could do it, but is not necessary, it just gets the updated data.).

Tip

  • The data_plugin_controller_signal in the MainController facilitates targeted communication between Analysis Tabs and the DataPluginController -> It optimizes plugin management by focusing on centralized interactions

  • Using this dedicated signal prevents the inefficiencies of cascading requests through the system’s hierarchy— a process that would typically scaling up to Main MVC and down to the DPMVC manually-resulting in delayed actions. This method not only simplifies maintenance but also supports easier scalability