Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "E4/Model Discussion"

< E4
(Contexts)
Line 49: Line 49:
  
 
What we really want in this case is to say that when MPart sets a value in its context, it is really set in its parent or grandparent, and so on. To achieve this we can add to the context notion of "control": the context says that it controls variable "abc". Then if its child context is asked to set "abc", it sets it on the parent context that declared itself as being in control of the "abc".
 
What we really want in this case is to say that when MPart sets a value in its context, it is really set in its parent or grandparent, and so on. To achieve this we can add to the context notion of "control": the context says that it controls variable "abc". Then if its child context is asked to set "abc", it sets it on the parent context that declared itself as being in control of the "abc".
 +
 +
'''Update:''' actually, we might be able to get by with adding a "modify" method. The "set" method sets value on the specific context it is invoked on; the "modify" goes up the chain of the contexts to find the context havong this value as local and changes it at that level. This will work for cases where we need to pass local selection from one view to another view.
  
 
* [Boris, Oleg] Debugging context events is not for a weak :-). In fact, it is next to impossible. We will probably need:
 
* [Boris, Oleg] Debugging context events is not for a weak :-). In fact, it is next to impossible. We will probably need:
 
** A debug view to explore context information for the MApplicationElement with info grouped in some logical way
 
** A debug view to explore context information for the MApplicationElement with info grouped in some logical way
 
** A view with animation of propagation of changes
 
** A view with animation of propagation of changes
 +
 +
* [Oleg] Null values vs. no values
 +
We'll need to either defile an Object NOT_A_VALUE or add a method "isSet()" to differentiate between cases where variable is set to null or not set.
 +
 +
* Maintaining links when reparenting
 +
Consider model viewer: A tree-like view with model elements that passes its selection to the specialized properties view. Ideally, if that properties view is dragged somewhere else in the E4 model we'd still like to receive selection from that original model viewer.
 +
This means that we need to be able to establish "links" that would survive changes of the context tree.
  
 
== Notifications / Events ==
 
== Notifications / Events ==

Revision as of 11:22, 15 July 2009

  • This is a page to collect semi-random thoughts on the E4 model, contexts, and notifications.

This page is intended to capture ideas and keep reminders for E4 developers. The information here is a work-in-progress and might change.

When you add a comment, please add comments in-line with the [my name] tag at the start.

How things work together

  • [Oleg <- McQ ] Model is static, context keeps state information?

To avoid duplication of information and questions on "which came first, the chicken or the egg?", we should keep the model static and use contexts to record state information.

Example: active part. There was a bug where model would change the active tab in the CTabFolder and send events. Event processing used context to get active part. Context was updated after the CTabFolder change. The fun result: commands were applied not to the currently selected editor, but to the previous editor.

[Eric] I'd rephrase that a bit. We have 3 'models' in play:

  • UI Model: This is where all persistent state should go. This model is not static, it contains the layout information which can be modified by the User. It's the one we should save/restore between E4 sessions.
  • Context: This is the model of the application's current state. It is highly dynamic, changing on every part activation... It has no persistent state and should be re-constructed on application startup.
  • CSS: This is a static model providing information that controls the 'look' of the application. While it's generally used to control widget properties such as text color, borders...we've recently been looking into whether it can be enhanced to provide model-specific feedback as well (such as which factory to use to render the model element).


Model

  • [anonymous :-)] Do we need different model elements for editors and views? If not, what is the test to satisfy backward compatibility?
  • [Oleg] MItemPart is unnecessary. Its attributes need to be moved into MPart (the attributes are optional anyway).
  • [Oleg] Perspectives are just Sashes with different styles for the tabs. We should not need a separate model element for MPerspective, rather a tag on the MSashForm
  • [Oleg] Names: "MSashForm" as opposing to MStack, MPart, MMenu, etc. Why not "MSash"?
  • [Oleg] Separation of models

We have the "basic" "application" model and "advanced" "workbench" model. I think this separation creates confusion rather then solves it. What we need is one model and 2 pictures: a UML diagram in the documentation with only "basic" elements shown and a UML diagram with both "basic" and "advanced" elements shown.

  • [Oleg] TODO make UML diagrams for the E4 model and put pictures somewhere in the doc/wiki.
  • [Oleg] A large number of typecasts used when walking the model. We need to either modify the EMF model or create wrappers / utilities to limit the number of typecasts (which are essentially implicit rules of what can go into the model).
  • [Eric] Question: what happens with persisted XMI models when we change model structure, say between Eclipse 4.0 and 4.1? Will we be able to read "old" models?

Contexts

  • [Oleg] The active child and selection

The selection currently follows active child. This is not always correct: For instance, when we click on a tab containing property view, that tab becomes active with null selection. However, the property view is really interested in the object that was selected in the previously active view, such as Project Explorer.

  • [Oleg] Replace output contexts with the concept of "controlled variable"

As an example, the combination of calculated values and artificial output context is currently used to implement selection service. This combination of the 2+ contexts and calculated values ala databainding is: a) hard to understand, b) not flexible (unless developer is willing to write more calculated values - see (a)), c) not efficient.

What we really want in this case is to say that when MPart sets a value in its context, it is really set in its parent or grandparent, and so on. To achieve this we can add to the context notion of "control": the context says that it controls variable "abc". Then if its child context is asked to set "abc", it sets it on the parent context that declared itself as being in control of the "abc".

Update: actually, we might be able to get by with adding a "modify" method. The "set" method sets value on the specific context it is invoked on; the "modify" goes up the chain of the contexts to find the context havong this value as local and changes it at that level. This will work for cases where we need to pass local selection from one view to another view.

  • [Boris, Oleg] Debugging context events is not for a weak :-). In fact, it is next to impossible. We will probably need:
    • A debug view to explore context information for the MApplicationElement with info grouped in some logical way
    • A view with animation of propagation of changes
  • [Oleg] Null values vs. no values

We'll need to either defile an Object NOT_A_VALUE or add a method "isSet()" to differentiate between cases where variable is set to null or not set.

  • Maintaining links when reparenting

Consider model viewer: A tree-like view with model elements that passes its selection to the specialized properties view. Ideally, if that properties view is dragged somewhere else in the E4 model we'd still like to receive selection from that original model viewer. This means that we need to be able to establish "links" that would survive changes of the context tree.

Notifications / Events

  • [Oleg] Whiteboard pattern / event bus

Related Defects

The following are defects that contain at least some discussion about architectural issues or suggestions on future direction:

  • 278631 Extensions and E4
  • 279681 E4 model: define events and lifecycles
  • 260408 {CSS} SWT requirements for CSS
  • 282901 {UI} Need better support for switching renderer to use
  • 248439 {E4} UI Model feedback
  • 264204 {Model} remove uses of 'Policy' to control orientation
  • 265171 Support different Stack types within the UI
  • 279263 {Compatibility} Consider addition of legacy view / editor containers
  • 280076 Make model loading plugable
  • 283040 Cleanup e4 terminology and API
  • 263820 {UI} Handlers seems to resolve their URIs early
  • 277947 Lets rename Eclipse RCP

Back to the top