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)
(Model)
Line 64: Line 64:
 
[Eric] I agree...the current separation of the models causes more problems than it solves. I'd also prefer to see a single model with basic and advanced (IDE) components.
 
[Eric] I agree...the current separation of the models causes more problems than it solves. I'd also prefer to see a single model with basic and advanced (IDE) components.
  
*[Oleg] make UML diagrams for the E4 model and put pictures somewhere in the doc/wiki - done:&nbsp;E4modelbeta.png and&nbsp;E4fullmodelbeta.png<br>.
+
*[Oleg] make UML diagrams for the E4 model and put pictures somewhere in the doc/wiki.
 +
 
 +
'''Done''':&nbsp;E4modelbeta.png and&nbsp;E4fullmodelbeta.png<br>.
  
 
<br>[[Image:E4modelbeta.png|thumb|center|200px|Base E4 model]]  
 
<br>[[Image:E4modelbeta.png|thumb|center|200px|Base E4 model]]  

Revision as of 11:38, 25 August 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.

Areas we'd like to work on

E4 Work areas
Area Interested
Contexts Oleg
Events Oleg
Model Editor Oleg
Row 4, Cell 1 Row 4, Cell 2
Row 5, Cell 1 Row 5, Cell 2
and so on... and so on...

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.

I like Eric's approach: persisted properties go in the model, non-persisted in the context.

[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?

[Eric] I'd be all for calling the current 'MPart' a 'View' and having what we currently think of as an 'Editor' be a 'View' with an 'Input'. Since we introduced savable and multi-instance views the only real remaining differences are containment restrictions (Editors and Views go into different stacks) and the extra mechanisms we allow for mapping resources onto editors.

  • [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"?

[Eric] All the names should be revisited, starting with removing the 'M' (I know I drove this change but, hey, I was wrong to trash the naming just to make the coding easier...;-). As far as 'MSash' goes perhaps it'd be better as 'MTiled'. The 'sash' is really an implementation detail, the real difference between an MStack and an MTile is that one only shows a single child at a time while the other shows them all.

  • [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.

[Eric] I agree...the current separation of the models causes more problems than it solves. I'd also prefer to see a single model with basic and advanced (IDE) components.

  • [Oleg] make UML diagrams for the E4 model and put pictures somewhere in the doc/wiki.

Done: E4modelbeta.png and E4fullmodelbeta.png
.


Base E4 model
Full E4 model


  • [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?
  • [Oleg] Does EMF help with model searches? We have number of places (most notably in WorkbenchPage) that repeat similar code pieces: find all parts, or all editors, or all modified parts, etc. Does EMF have a built-in fast way to walk the model?
  • [Oleg] Menu items should have "isChecked" (Project -> Build Automatically.)
  • [Oleg] We should be able to bring part to top without activating it. Example: editor might need to be brought to top of the editor stack without activating it.

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"

Done: IEclipseContext.modify() + IEclipseContext.declareModifiable(). There are two remaining uses of IContextConstants.OUTPUTS; they will be cleaned up.

  • [Boris, Oleg] Debugging context events is not for the 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

[Eric] Agreed, I've been working (very part-time) on one of these for 2 months...Moreover I think that having the tooling to visualize and manipulate all three of our models (UI Mode, Context, CSS) is really important, it's our proof that we know what we have and how it works. Also, the implementation of these views will be a direct reflection of the complexity of the underlying model; if we find it hard to keep these views in synch with ongoing changes it's a sign that we're going in the wrong direction (i.e. the current UI Model Editor is < 1000 lines of java...if it starts to get a bunch of funky if statements and switches it's likely that we're making the actual model overly complex).

  • [Oleg] Null values vs. no values

We'll need to either define 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.

Life Cycle

  • [Eric] One of the areas that really needs immediate attention is defining the life cycle of the application and, as a subset, the life cycle of the parts within it. Not having really clear states is leading to the code being somewhat arbitrarily located; we just put it 'where it works' as opposed to identifying what the code is doing and then placing it into some well-defined slot for that type of code.

For example here's a possible state diagram for an application:

  • Starting: the application is initializing
    • App Init: define the App's Context and populate any 'core' services, variables...
    • Workspace init: Open a Workspace to use or create a new one
    • CSS Init: Locate a CSS definition (if any) and set up the engine.
    • Model Init: Populate the initial UI Model instance. This may be some combination of loading a saved model plus changes needed to handle extensions...
  • Running: The UI (if any) is up and the application is usable
    • Nornal: What we usually see
    • Dialog/Wizard: A dialog/wizard is up. We need to remap keybindings...
  • Shutting Down: The application is on the way down; note that we wouldn't enter this state until we're sure we're actually shutting down, all queries (save editors...) that could lead to a cancel of the close have already been processed...

If we allow clients to place code between the states (i.e. 'Pre Workspace Init' or 'Post Model Init'...) then they have logical slots for most tweaks, additions...

I think it'd be a good idea to actually have the code reflect that this is a state machine, allowing for the addition of new states and or replacement of the default implementation of a particular state.

Notifications / Events

  • [Oleg] Whiteboard pattern / event bus
  • [Eric] I'm quite interested in this but I'm not sure whether the two ideas are the same. Could you and Tom post a thumbnail explanation of them? Whatever strategy we come up with it should be the only one we use; if it's a 'global' listener (ContentAdapter) then we should use just the one for all model eventing.
  • [Eric] We should also see what events we should add into E4 and then use those events to implement the events in the compatibility layer using a translate and forward mechanism.

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
  • 280962 New workbench part is instantiated everytime setVisible(true) is called on an MContributedPart

Back to the top