Home » Eclipse Projects » GEF » [GEF4] GridLayout / Spreadsheet
|
| Re: [GEF4] GridLayout / Spreadsheet [message #1747472 is a reply to message #1747094] |
Tue, 15 November 2016 04:34   |
Eclipse User |
|
|
|
Hi Onke,
so you have the following model: One Group object contains multiple Entry objects which have a category assigned, i.e. class Model { List<Group> groups; List<Category> categories; }
class Group { String label; List<Entry> entries; }
class Entry { String label; Category category; }
class Category { String label; }
There are different approaches to that: 1) ModelPart that directly renders groups, categories, and entries; 2) ModelPart that directly renders groups and categories, but reports entries as content-children, so that EntryPart renders a single entry (ModelPart handles insertion/removal of EntryParts and their visuals); 3) ModelPart that only renders the GridPane and handles the insertion/removal of GroupPart, CategoryPart, and EntryPart, which render their labels/data themselves.
Depending on how you want to tailor the content-parts, the ModelPart's methods need to be implemented in a certain way:
1) ModelPart has the Model as content, no content-children (doGetContentChildren()), one GridPane visual (createVisual()) that is filled with groups, categories, and entries during doRefreshVisual().
2) ModelPart has the Model as content, returns entries as content-children, and renders a GridPane that is filled with groups and categories during doRefreshVisual(). Entries are controlled by EntryPart, therefore, ModelPart needs to implement addChildVisual() and removeChildVisual(), which insert the given child into the respective grid cell.
3) ModelPart has the Model as content, returns groups, categories, and entries as content-children, and renders a GridPane. doRefreshVisual() does nothing. Groups, categories, and entries are controlled by GroupPart, CategoryPart, and EntryPart, respectively, therefore, ModelPart needs to implement addChildVisual() and removeChildVisual(), which insert the given child into the respective grid cell.
The content-parts are organized in a hierarchy, but the underlying model does not need to be organized. Complementary to the content-part hierarchy, you can use anchorage-anchored relations between any content-parts. Generally, these are used to connect parts that are not connected via their parent-child relation, e.g. connections and labels.
Best regards,
Matthias
|
|
| |
| Re: [GEF4] GridLayout / Spreadsheet [message #1754260 is a reply to message #1754210] |
Wed, 15 February 2017 15:19 |
| Eclipse User |
|
|
|
Hi Onke,
in order to refresh the visualization of a content part, the IContentPart#refreshVisual() method needs to be called on that part.
Usually, content parts register listeners for content changes from their doActivate() method -- which can be unregistered from doDeactivate() -- and call refreshVisual() when a change occurs. If your model is observable, i.e. providing a mechanism to notify listeners about changes -- such as IPropertyChangeNotifier as in the TextNode example, or javafx.properties and the GEF Common.beans.property complements -- this is the way to go.
If your model is not observable, then all model changes could be chanelled through the content parts, and/or be encapsulated in operations (ITransactionalOperation) from which you can call refreshVisual(). Encapsulating the changes in operations does also enable undo/redo.
The framework provides ITransformable-, IResizable-, and IBendableContentPart interfaces so that the related default policies and operations can be used, which call an interface method on the content part to set a visual/content transformation, visual/content size, or visual/content bend points, respectively. Therefore, the content-related code remains within the specific content parts.
All in all, in order to keep all content-related code within the corresponding parts, you can provide an API via the specific content parts to perform changes on the corresponding content / part of the model. In order to keep all model changes undoable, they should be encapsulated in operations that use the specific content part APIs to perform the model changes. When the model is changed via the API, refreshVisual() is either directly called, or from a listener, set up during activation, that is notified about the change. But you could also let the operations call refreshVisual(). Besides, SetRefreshVisualOperation (or IContentPart#setRefreshVisual()) can be used to prevent unnecessary refreshs.
If you have any more questions, feel free to ask 
Best regards,
Matthias
[Updated on: Wed, 15 February 2017 15:27] by Moderator |
|
|
Goto Forum:
Current Time: Thu Apr 24 03:46:22 EDT 2025
Powered by FUDForum. Page generated in 0.03725 seconds |
Home