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
