Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » GEF » [GEF4] GridLayout / Spreadsheet
[GEF4] GridLayout / Spreadsheet [message #1747094] Wed, 09 November 2016 11:32 Go to next message
Onke Wagner is currently offline Onke WagnerFriend
Messages: 2
Registered: November 2016
Junior Member
Hi all,

I'm developing a GEF4 application (which should be used as an eclipse plugin). I've done a lot of research and looked at the MVC example on github but one question still remains.

The requirement that I have is that the view has to "look" like a spreadsheet or something like that. The model can shortly be described as follows: we have different categories on the x axis and some groups on the y axis. Each category has one column assigned. For the groups there can be multiple entries in one row (nested).

Since my knowledge in GEF is very limited and I haven't found any useful stuff on the internet, is it possible to realize something like that? I stuck on how to design the data model / how to model my requirements correctly. That means how to dynamically build a grid and put the content in the correct cells (matching category and group). The data is read from an EMF instance. In a pure JavaFX Application, I have used a GridPane and added nested GridPanes where necessary to handle the nested y-rows, it works. I have attached a screenshot of the view of this small application. But I have no idea how to get a good starting point for doing this with GEF / how to put my data in a model that can be used.

index.php/fa/27539/0/

Thanks for any hints!
Re: [GEF4] GridLayout / Spreadsheet [message #1747472 is a reply to message #1747094] Tue, 15 November 2016 09:34 Go to previous messageGo to next message
Matthias Wienand is currently offline Matthias WienandFriend
Messages: 230
Registered: March 2015
Senior Member
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; }
You want to display one column per category, display one row per group, and display the entries in the correct cells.

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 #1754210 is a reply to message #1747472] Wed, 15 February 2017 13:03 Go to previous messageGo to next message
Onke Wagner is currently offline Onke WagnerFriend
Messages: 2
Registered: November 2016
Junior Member
Hi Matthias,

thank you very much for your suggestions and sorry for my late answer. In the meantime I've implemented approach 1) . I have a question now / couldn't figure out how this works:
When I update the category of an entry in the UI and set it back to the model via any setter-method of my model, how do I tell GEF to refresh the visuals? I haven't found any (working) example on how to achieve this. https://github.com/caochun/gef4.mvc.tutorials/blob/master/gef4.mvc.tutorial3/src/gef4/mvc/tutorial/model/TextNode.java seems to do something quite similar by implementing the IPropertyChangeNotifier interface, but I did not found it in the version of gef I am using (importing via Dependencies tab in Manifest in an eclipse plug-in project, org.eclipse.gef.common (5.0.0)).

Any hints / links on this?
Thanks, Onke
Re: [GEF4] GridLayout / Spreadsheet [message #1754260 is a reply to message #1754210] Wed, 15 February 2017 20:19 Go to previous message
Matthias Wienand is currently offline Matthias WienandFriend
Messages: 230
Registered: March 2015
Senior Member
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 Smile

Best regards,
Matthias

[Updated on: Wed, 15 February 2017 20:27]

Report message to a moderator

Previous Topic:How to apply css for gef geometry
Next Topic:Problems with figure order
Goto Forum:
  


Current Time: Sat Apr 20 04:02:56 GMT 2024

Powered by FUDForum. Page generated in 0.03537 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top