Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse 4 » What "Position in List" means ?
What "Position in List" means ? [message #725790] Thu, 15 September 2011 15:10 Go to next message
Cristiano Gaviao is currently offline Cristiano Gaviao
Messages: 253
Registered: July 2009
Senior Member
Hi again,

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?

thanks

Cristiano
(no subject) [message #725988 is a reply to message #725790] Fri, 16 September 2011 06:39 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5296
Registered: July 2009
Senior Member
Allowed values are:

* first
* index:$theindex$
* before:$theotherelementsid$
* after:$theotherelementsid$

Tom

Am 15.09.11 21:10, schrieb Cristiano avi:
> Hi again,
>
> 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?
>
> thanks
>
> Cristiano
Re: (no subject) [message #726076 is a reply to message #725988] Fri, 16 September 2011 10:04 Go to previous messageGo to next message
Bj is currently offline Bj
Messages: 2
Registered: September 2011
Junior Member
Hello Tom,

how is the menu constructed if using index:$theindex$ for assigning the item positions? Are all model fragments of all bundles are evaluated first and the menu is constructed then, or is the menu constructed step by step after every loaded bundle?

The reason for my question is the following problem (The described scenario is simplified but similar to the factual one):

I have an application.e4xmi file defining the base model in the bundle org.test.platform.ui. In that base model I have a TrimmedWindow containing a menu. This menu contains five sub menus. For sub menu number 3 there are no items defined in the base model, because they are contributed through other bundles.

Now in my bundle org.test.sub1.ui I have a fragment.e4xmi file defining a model fragment, that contributes 2 StringModelFragment each with one HandledMenuItem:

<fragments xsi:type="fragment:StringModelFragment" xmi:id="_YjeEoN-dEeCuaLL5mc3fCA" featurename="children" parentElementId="menu:org.test.platform.ui.menu.extra" positionInList="index:0">
    <elements xsi:type="menu:HandledMenuItem" xmi:id="_aqeNYN-dEeCuaLL5mc3fCA" label="Menu Entry 0" command="_dYhIAN-dEeCuaLL5mc3fCA"/>
  </fragments>
  <fragments xsi:type="fragment:StringModelFragment" xmi:id="_zJJ_QN-cEeCuaLL5mc3fCA" featurename="children" parentElementId="menu:org.test.platform.ui.menu.extra" positionInList="index:2">
    <elements xsi:type="menu:HandledMenuItem" xmi:id="_6LKpcN-cEeCuaLL5mc3fCA" label="Menu Entry 2" command="_XzTocN-cEeCuaLL5mc3fCA"/>
  </fragments>


In an other bundle bundle org.test.sub2.ui I have also a fragment.e4xmi file defining a model fragment, that contributes 2 StringModelFragment each with one HandledMenuItem:

<fragments xsi:type="fragment:StringModelFragment" xmi:id="_YjeEoN-dEeCuaLL5mc3fCA" featurename="children" parentElementId="menu:org.test.platform.ui.menu.extra" positionInList="index:1">
    <elements xsi:type="menu:HandledMenuItem" xmi:id="_aqeNYN-dEeCuaLL5mc3fCA" label="Menu Entry 1" command="_dYhIAN-dEeCuaLL5mc3fCA"/>
  </fragments>
  <fragments xsi:type="fragment:StringModelFragment" xmi:id="_zJJ_QN-cEeCuaLL5mc3fCA" featurename="children" parentElementId="menu:org.test.platform.ui.menu.extra" positionInList="index:3">
    <elements xsi:type="menu:HandledMenuItem" xmi:id="_6LKpcN-cEeCuaLL5mc3fCA" label="Menu Entry 3" command="_XzTocN-cEeCuaLL5mc3fCA"/>
  </fragments>


If I run the Application, the result is something like the following

Menu Entry 1
Menu Entry 3
Menu Entry 0
Menu Entry 2

what am I doing wrong?

Thanks a lot. I tried a lot today to get this behaviour under control, but without any success.

Björn
Re: (no subject) [message #726083 is a reply to message #726076] Fri, 16 September 2011 10:15 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5296
Registered: July 2009
Senior Member
Am 16.09.11 16:04, schrieb Bj:
> Hello Tom,
>
> how is the menu constructed if using index:$theindex$ for assigning the
> item positions? Are all model fragments of all bundles are evaluated
> first and the menu is constructed then, or is the menu constructed step
> by step after every loaded bundle?

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:

* my.plugin.1
* my.plugin.2

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.

If you need ultimate control over the model construction you can always
reside to a processor where you get the model passed in your java code
and execute ANY logic you want to.

Tom
Re: (no subject) [message #726641 is a reply to message #726083] Mon, 19 September 2011 02:02 Go to previous messageGo to next message
Bj is currently offline Bj
Messages: 2
Registered: September 2011
Junior Member
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:

* my.plugin.1
* my.plugin.2

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.
Tom


Hello Tom,

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?

cheers Björn


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?

thx

[Updated on: Mon, 19 September 2011 03:18]

Report message to a moderator

Re: (no subject) [message #989419 is a reply to message #726641] Thu, 06 December 2012 02:39 Go to previous messageGo to next message
sumit singh is currently offline sumit singh
Messages: 131
Registered: October 2012
Location: Bangalore
Senior Member

first --> Positions the element on the beginning of the list.
index: --->Places the new model elements at position theindex.
theindex Example
index:0


before=theotherelementsid --> theotherelementsid theotherelementsid Places the new model elements before the model element with the ID theotherelementsid.
after=theotherelementsid --> Places the new model elements after the model element with the ID theotherelementsid.
Re: (no subject) [message #989427 is a reply to message #989419] Thu, 06 December 2012 03:13 Go to previous message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5296
Registered: July 2009
Senior Member
Do we have a tooling bug for this? I think the editor should support
people with this syntax.

Tom

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
> theotherelementsid.
> after=theotherelementsid --> Places the new model elements after the
> model element with the ID theotherelementsid.
Previous Topic:Tooltip on viewer item when using AdapterFactoryLabelProvider
Next Topic:When does the system inject @Optional annotated fields?
Goto Forum:
  


Current Time: Mon Sep 01 03:49:26 EDT 2014

Powered by FUDForum. Page generated in 0.02621 seconds