110 likes | 126 Views
This proposal aims to enhance the flexibility of debug views update policy by allowing different view update policies, specialized updaters, and handling multi-target views efficiently. By replacing static event handlers with pluggable updaters, this system will provide better control to models and views, making the debugging process more efficient and customizable. It introduces a new scheme for generic debug views to separate logic from updates, ensuring easy migration and enhanced extensibility.
E N D
Agenda • Background • Requirements • How does it work now? • How to make it more flexible?
Background • Debug Views Update is inflexible and is driven by a pre-defined set of events. • Model cannot control when / how updates are to be commenced • Difficult to define a strategy that is suitable for all debug adapters.
Requirements • Make debug views update more flexible – give models better control. • Allow a view to have different update policies. • Allow models to specify different update policies for different views. • Example Policies: • Update what’s visible • Update nothing • Update all • Periodic update • Etc.
How to make it more flexible? • Replace static event handler with pluggable updaters. • Updater are bound to a view using the view id and the model identifier of the input element. • Create updater when new input is set to the view. • Updater controls when view is to be populated.
How to make it more flexible? • Specialized updaters • Selection Event Updater • Debug Event Updater • Delayed Debug Event Updater • Timer Updater • Preference Store Changed Updater • Etc. • Updaters are responsible for controlling when a view gets content from the model. • Extends IDebugView: IDebugViewExtension. • APIs to allow updaters to update views. • Debug Platform is to provide implementations to some generic updaters. • Clients can also implement their own updaters.
Contributing Updaters – extension point • Clients can contribute an updater to a specific view. • Updaters are bound by model identifier and view id. • If no updater is specified, a debug view uses its current event handler as its updater.
Handling Multi-Targets View • Views showing content from different targets simultaneously. • Example: Debug View, Expression View • View has static view input. • Retrieve updater as new models are added. • Updaters are responsible to update elements from its model, not the entire view. Multi-Targets View Static View Input Updater 1 Model A Updater 2 Update (elementA) Model B Updater 3 Update (elementB) Model C Updater 4 Update (elementC)
Fitting into the new scheme… Generic Debug View • Separate out logic of view updates from view. • Updaters have no knowledge about its view. • View updates are performed via a generic interface. • Views are not tied to any updater. • View event notifications are also performed via a generic interface. • Generic View needs to handle view updater extension point and honor contributed updaters. • Easy to migrate. IDebugElement IDebugElement Generic Interface for View Events Notification Generic Interface for Update (Update an element and its children) View Updaters