1 / 18

Update Policy and Model Proxy for View Updating

This update discusses the design and implementation of an update policy and model proxy for manual and independent view updating. It includes the challenges and issues faced, as well as future plans for the next release.

knights
Télécharger la présentation

Update Policy and Model Proxy for View Updating

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Update Policy ~ Where we are in 3.2

  2. Agenda • Overview of Design • Design of a Prototype • What you can do in 3.2 • Challenges / Issues • Plans for Next Release

  3. Overview of Design • Update Policy has been split off into two components: • Update Policy • Model Proxy • Update Policy • Tightly coupled with the viewer • Created once when the viewer is created • Model Proxy • Platform provides default adapter for model proxies: • E.g. variables view model proxy, expression view model proxy • Clients can create model proxy by providing adapter to IModelProxyFactoryAdapter • Install when an element with a new model proxy is mapped to a view

  4. Update Policy + Model Proxy Update Policy update fires deltas Viewer Model Element Model Proxy Factory Model Proxy installs Presentation Context

  5. Building an Manual Update Policy • Goal: • Build an update policy that allow user to freeze a view and update manually. • Step 1: • How should this be implemented? • Option A: Change update policy in the viewer when user decides to freeze the view. • Option B: Model Proxy to stop firing events when the view is frozen. • Result: Option B. • There is really no API to do Option A.

  6. Step 2: Design of the Prototype • Create action in Variables View to disconnect the view from model. • When a view is disconnected, the view will stop updating. • Create action in Variables View to refresh view manually. • The view will be refreshed even if it is disconnected. • Set up preference for connecting and disconnecting views. • Demo

  7. Step 2: Design of the Prototype Update Policy Get Preference [Disconnect?] Preference Store update fires deltas Viewer modify Element Customized Model Proxy Model Proxy Factory Disconnect Action installs Presentation Context Debug Events Model

  8. Step 3: When View and Model are Out-of-Sync • Problem: View and Model cannot be updated independently • View always gets the latest and greatest when: • Update policy receives a model changed event • Input is changed in the view (due to changes in debug context) • Caused the view to be updated even when it should not be updating. • Content needs to be cached in order to allow views and models to update independently. • Get current data after the model is changed • Return cached data otherwise • Benefits: • Performance • Allow view and model to update independently • Also allows views that show the same data to update independently. • E.g Multiple Variables View, Renderings in Memory View

  9. Background: Content Adapter 3. Return Children • Content Adapter defined by type. • Shared among views. • E.g. Variables and Registers View share stackframe content adapter Viewer Element 1. #getAdapter Model Viewer Content Adapter Element 2. Get Children Presentation Context

  10. Step 4: Caching by Model View Cache [view id] [debug context] View Cache [view id] [debug context] • The content adapter is asked to get children. • The content adapter asks for cache based on presentation context and debug context. • If cache is empty, the content adapter gets children from its model. • The content adapter makes a copy of the data and store it in the cache. • Content adapter marks view cache as updated. 3. Cache Data & Mark Updated Model Create and Manage View Cache Manager [Debug Target] 1. Get Cache Content Adapter 2. Get Children

  11. Step 5: View Update with Cache View Cache [view id] [debug context] View Cache [view id] [debug context] 2. Check #isStale() 3b. Get Children • Model Proxy fires a change event. • Viewer’s update policy receives the change event and asks the viewer to update. • The viewer asks the content adapter for children again. • The content adapter retrieves the correct cache from View Cache Manager. • The content adapter checks if the cache is stale. • If the cache is stale, the content adapter gets updated children from its model • If cache is not stale, the content adapter asks the cache for children and return those children. Model Get Cache View Cache Manager [Debug Target] 1. Get Cache Content Adapter 3a. Get Children

  12. Step 6: Cache Update View Cache [view id] [debug context] View Cache [view id] [debug context] • Debug session is resumed. • Model tells the cache manager that the cache has become stale. • View Cache Manager goes through its view caches and mark them all as stale. • Cache is updated when the same data is required again. 2. Mark Stale 2. Mark Stale Model 1. Model Resume View Cache Manager [Debug Target]

  13. Step 7: … when view is disconnected View Cache [view id] [debug context] View Cache [view id] [debug context] • Content adapter may still be asked to get children (input changed, after resume.) • Content adapter gets the correct cache and checks if cache is stale. • Content Adapter also checks the disconnect preference and see if the view is disconnected. • If view is disconnected, content adapter returns children from cache if it is stale. • Otherwise, content adapter gets current data from model. 2. #isStale() 4a. getChildren Model Get Cache View Cache Manager [Debug Target] 1. Get Cache Content Adapter 4b. Get Children Viewer 3. Get Disconnect Preference Preference Store 5. Return Children

  14. What you can do in 3.2 • Model Proxies allow clients to control how and when debug events are to be handled. • To implement update policies: • Client must define model-specific preference and actions for switching between update policies. • Clients must implement customized model proxies to fire and filter events accordingly. • Clients must implement customized content adapter to cache data and clear cache as necessary. • What we have in 3.2 is a start to allow clients have more control over view updates. We have still have many unanswered questions.

  15. Challenges and Issues • Update Policy is too tightly coupled with a viewer. • Cannot be easily overridden • Should clients be allowed to contribute update policies in views? (i.e. replace the update policy in the viewer.) • Update Policy is installed in a view and shared among models. It may not be such a good idea to allow a model to swap out a view’s update policy. • Need a way to restore original update policy when a model is disposed. • No clear definition of responsibilities between update policies and model proxies. • When implementing an update policy, it is unclear where it should be implemented. • This implementation of model policy is model-specific. • Unable to create generic update policies to be shared and reused.

  16. Challenges and Issues • Expansion & Scrolling • Virtual Tree Viewer • Potentially cause the view to show a mix of stale and updated data. • Example: View Frozen -> Step -> Expand a node • Prototype stops asking for children if content cache is not up-to-date. • Ability to disable actions in views • E.g. Logical Structure, show type names, modifying values • May not be able to support these features when data is stale • Need to be able to disable these features when needed • View population is asynchronous • Difficulties when implementing a timer update policy: • Unable to tell when a view has finished updating and that the model is ready to be resumed. • When there is more than one view updating, how can a model tell when all views have finished updating before it can resume.

  17. Challenges and Issues • Show Changes in View • Model is responsible to mark changes (IVariable#hasValueChanged) - except for Memory View. • OK if there is only view showing the variables. • Model gets polluted when there are multiple views showing the same data. Models cannot reliably determine changes for a view. • Multiple Views on showing the same thing while on different update policy • Need to show that views are on different update policies • Need strategy for caching to ensure that views update independently • E.g. Memory View, Multiple Variables View • How to show that data is stale? • Idea: Set view to a different font before view update. • When the view has finished updating, set it back to its original font.

  18. … Next Release • Workgroup to tackle some of the issues with update policies. • Define use cases and update policies. • Outline how some of the update policies would be implemented. • Clarify responsibilities of update policy and model proxy. • Tackle the problems outlined on previous slides.

More Related