|What "Position in List" means ? [message #725790]
||Thu, 15 September 2011 15:10
| Cristiano Gaviao
Registered: July 2009
In my tests I did a contribution. I have create a String Model Fragment pointing to menu:org.eclipse.ui.main.menu and used 'children' for Featurename.
As I'm contributing to a list of other objects, I thought that 'Position in List' would put my contributed menu in some fixed position related of others in that list...
So I've tried the number 1 for this model field.
The result was a silent error. e4 gives me the following message in red: Not a valid list position.
could someone give me some explanation on that?
|Re: (no subject) [message #726641 is a reply to message #726083]
||Mon, 19 September 2011 02:02
Registered: September 2011
Tom Schindl wrote on Fri, 16 September 2011 10:15|
Am 16.09.11 16:04, schrieb Bj:
They are constructed step by step or better said IConfigurationElement
by IConfigurationElement so by default the ordering is random (based
upon in which order the extension registry parsed the files).
But there's one thing that help you to get a defined order because we
are sorting the contributions before executing them based upon
dependencies say you have:
If you now make a my.plugin.2 depend on my.plugin.1 the algorithm we
have in our ModelAssembler (=the class which merges in the fragments and
launches the processors) ensures that all fragments from my.plugin.1 are
merged before the ones from my.plugin.2.
thank you for your reply, but it confuses me a little.
Let's say that my.plugin.1 defines the menu contributions for item 1 and 3 in a specific menu and my.plugin.2 defines item 0 and 2. If we now make a dependency from my.plugin.1 to my.plugin.2, the one which is merged firstly would be my.plugin.1.
So the result order would be: 0, 2, 1, 3? For me that means allocating the "Position in List" attribute using index:$theindex$ would have not really an effect because the item is not contributed considering the defined list index or am I wrong?
EDIT: My confusing has itself taken care. In the upper described scenario the resulting order would be correctly 0, 1, 2, 3.
The problem I have is, that e.g. my.plugin.1 defines the items 0, 1, 6, 7, my.plugin.2 defines the items 4, 5 and my.plugin.3 defines the items 2, 3.
So the process would be something like
load my.plugin.1 --> 0, 1, 6, 7
load my.plugin.2 --> 0, 1, 6, 7, 4, 5 (because 4 and 5 are correctly allocated at their positions)
load my.plugin.3 --> 0, 1, 2, 3, 6, 7, 4, 5
I am not able to make the three plugins depending from each other because of the applications architecture. Any idea how to fix this problem?
[Updated on: Mon, 19 September 2011 03:18]
Report message to a moderator
|Re: (no subject) [message #989427 is a reply to message #989419]
||Thu, 06 December 2012 03:13
| Thomas Schindl
Registered: July 2009
Do we have a tooling bug for this? I think the editor should support|
people with this syntax.
Am 06.12.12 08:39, schrieb sumit singh:
> first --> Positions the element on the beginning of the list.
> index: --->Places the new model elements at position theindex.
> theindex Exampleindex:0
> before=theotherelementsid --> theotherelementsid theotherelementsid
> Places the new model elements before the model element with the ID
> after=theotherelementsid --> Places the new model elements after the
> model element with the ID theotherelementsid.
Powered by FUDForum
. Page generated in 0.12399 seconds