Summary: | Changed behavior for placeholder and part IDs | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Gerhard Kreuzer <gerhard.kreuzer> | ||||
Component: | UI | Assignee: | Platform-UI-Inbox <Platform-UI-Inbox> | ||||
Status: | NEW --- | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P3 | CC: | gerhard.kreuzer, Lars.Vogel, rolf.theunissen, tom.schindl | ||||
Version: | 4.15 | ||||||
Target Milestone: | --- | ||||||
Hardware: | PC | ||||||
OS: | Windows 10 | ||||||
See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=509644 https://bugs.eclipse.org/bugs/show_bug.cgi?id=573537 |
||||||
Whiteboard: | |||||||
Bug Depends on: | |||||||
Bug Blocks: | 562497 | ||||||
Attachments: |
|
Description
Gerhard Kreuzer
2020-04-24 11:23:35 EDT
This a regression of the fixes for Bug 509644. As result of that change, all elements in all contributed fragments must have a unique ID, otherwise they are not processed correctly. That is, some elements will be silently ignored. AFAIK uniqueness of identifiers is not an requirement for the E4 model. If this is a requirement it should be validated and errors should be logged if this is violated. Workaround is indeed to have an unique ID for each element. Some IDs are not unique by design, e.g. the top level menu of every window should have the same id I discovered the "solution" by playing around and did not try to understand the behavior by studying the source code. So when recognizing the pattern, that referenced elements and their placeholders should carry different IDs, I applied this scheme to all placeholder element pairs in my app, including an Area and its placeholder. But in the case of the Area providing different IDs did not work, but messed up the app's layout... Furthermore (Javadoc excerpt of org.eclipse.e4.ui.model.application.ui.advanced.MPlaceholder.java(27-30) (Eclipse V4.15)): ... * A Placeholder is a concrete class used to share elements between perspectives. The * elements referenced by a Placeholder generally exist in the Window's 'sharedElements' * list. By convention a placeholder usually shares the same elementId as the element * that it's referencing. ... Is there some documentation of the precise details concerning this ID issue? IMHO it is a bit unsatisfactory because I'm missing a comprehensible rule set when to do what. How should we settle this issue? I would prefer, to reenable the same IDs for placeholders and their referenced elements, because it is documented this way. Or for consistency reasons to force different IDs for all placeholder / element pairs. The second solution has the weakness, that we probably will not be able to find and update all existing documentation, where the Javadoc above is cited in some way. [I’m wondering: the fixes for Bug 509644 are over three years old - am I really the first one who stumbled into this?] The handling of non-unique elements is wrong in the ModelAssembler that merges the fragment elements into the main model. So the behavior of Eclipse is wrong here. Fragments are not that commonly used, especially not to define the main structure of the application. Therefore, nobody stumbled on this issue yet. There are more known bugs related to merging fragments into the application Why do you model large parts (the full?) application in fragments? You could define the main structure in the Application or Perspective. Then you would not need the merging of all the fragments. Rolf, thanks for your quick reply. In order to understand the reasoning behind the design and architecture of the cited app, I must give some context information. The app I'm speaking of is kind of engineering tool / IDE for our engineering staff. There are quite a few users spread over different departments and therefore there are a lot request and requirements concerning the functionality. Some time ago the idea was born, that we provide a kind of highly modular basic app (i.e. "toolkit") to enable "community development" ("We provide the means, so that you can help yourself.") When looking out for the basic technology, we decided to use Eclipse RCP and when we started to design and code our tool (at the time of Eclipse Oxygen), we were not sure, whether we should build on pure E4 technology or include the compat layer. Your decision at that time was to start out with pure E4, but to develop in a way, so that we could easily switch to a compat-layer based app (if we should encounter the necessity to include a E3 based plug-in or alike). The aim was, that only the application providing plug-in itself should have to be exchanged in order to switch between E4 and E3. These decisions led to our app as it is. It is still pure E4 and will presumably stay so, but the highly modular design with clear separation of concerns (which also led to a heavy use of model fragments) proved as benefit. Furthermore, our released app is still bound to Eclipse Oxygen, because it costs some effort to switch the basic framework (due to internal restrictions). But to be prepared, we recently decided to always port to the latest framework version and maintain our code base in a way to support the current released product and the latest framework version. The goal here is to have a single source base where only the manifest files and product definition should need to be adapted. Currently I have no severe problems in realizing our goals with the current framework, but I hope to help to improve the overall quality of the Eclispe framework, by reporting peculiarities we encounter along the way. I agree with Rolf, this is a regression and needs to be fixed by the platform. The good thing is that you have a work around for the time being. |