Merged context - use cases

This paper summarizes known use cases for merged contexts. Merged context is discussed in issue 34057.

Related documents:

1. Just merge actions from set of  Contexts 

Description

This use case comes originally from issue  33980, which basically request  merging actions from two or more Contexts (Editors/$type/) just only for reading. All merged contexts may come from the same RootContex (in other words from the same implementation of BaseContext and RootContext).

Requested:

  • take precedence in case of name conflict
  • support for ordering

Not requested:

  • reverting
  • masking
  • where to store changes, so no active context  needed
  • dynamically change merged contexts

2.  Inheritance of project settings

Description

This use cases is slightly described in issue 34057 (see also 34551).  According to project settings API there exist Configurable objects,  which can have settings attached to them. Moreover there may exist dependencies among such objects.   Dependency here means ability to inherit settings or overlay inherited settings. Settings for every Configurable object (CO) are stored and read from its own Context (Ctx). There is requested to merge individual Contexts (delegates) into MergeContext (MCtx) to ensure inheritance of settings. Dependencies for CO may change, then inheritance hierarchy must change and then delegates for MCtx must change.  There must exist one active CO at any time, which may be changed,  so all modifications of setting must go into Ctx for active CO.  There is necessary to have information if setting was modified and be able to revert it to the original value. There is no special  need for deleting neither settings nor subcontexts, so there is not requested to support masking (or have  information about masking).

Requested:

  • MCtx must merge arbitrary number of Ctx
  • take precedence in case of name conflict
  • dynamically change merged contexts
  • one and only one  delegate is active, that can be dynamically changed
  • have information about modifications
  • revert modifications

Not requested:

  • masking  or  have knowledge  about deleted masked files and attributes

2.  OK,Cancel Support for Tools/Options 

Description

This issue relates with 23359. See also User Interface Specification for System Options. The main purpose of this issue is actually implement OK, Cancel logic for Tools/Option dialog. Currently the problem  is, that modified setting and services are instantly saved and serialized. But changes shouldn't apply until OK button is pressed and on the other hand pressing of Cancel must revert all changes.  One of the possible solutions could be to read settings from Context , but  don't  propagate modifications back to the same Context.  So, there exist temporary context and all modifications should go into this context.  Empty temporary context (TCtx) and original context (OCtx) are considered as delegates and are expected to be merged together into MCtx. Then TCtx is active and  all modifications go into.  If Cancel is pressed, than TCtx is simply emptied. If OK is pressed, than all modifications from TCtx are propagated into OCtx and TCtx is emptied.
Be aware, that this implementation has one  important problem with settings implemented as singletons, but this is not important for this document.

Requested:

  • merge of OCtx and TCtx, where Octxt is preceded by TCtx
  • TCtx is always active
  • masking  or  have knowledge  about deleted masked files and attributes (definitely at least for deleted services)
  • revert all changes at once
  • propagate  changes from TCtx to OCtx

Not requested:

  • dynamically change active context
  • dynamically change merged contexts

Project Features

About this Project

openide was started in November 2009, is owned by Antonin Nebuzelsky, and has 92 members.
By use of this website, you agree to the NetBeans Policies and Terms of Use (revision 20160708.bf2ac18). © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo
 
 
Close
loading
Please Confirm
Close