Eclipse Community Forums: Eclipse 4 » What "Position in List" means ?

Help

Home

Home » Eclipse Projects » Eclipse 4 » What "Position in List" means ?

Show: Today's Messages :: Show Polls :: Message Navigator

What "Position in List" means ? [message #725790]

Thu, 15 September 2011 19:10

Cristiano Gavião

Messages: 279
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

Report message to a moderator

(no subject) [message #725988 is a reply to message #725790]

Fri, 16 September 2011 10:39

Thomas Schindl

Messages: 6651
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

Report message to a moderator

Re: (no subject) [message #726076 is a reply to message #725988]

Fri, 16 September 2011 14:04

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

Report message to a moderator

Re: (no subject) [message #726083 is a reply to message #726076]

Fri, 16 September 2011 14:15

Thomas Schindl

Messages: 6651
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

Report message to a moderator

Re: (no subject) [message #726641 is a reply to message #726083]

Mon, 19 September 2011 06:02

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 07:18]

Report message to a moderator

Re: (no subject) [message #989419 is a reply to message #726641]

Thu, 06 December 2012 07:39

Sumit Singh

Messages: 141
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.

Report message to a moderator

Re: (no subject) [message #989427 is a reply to message #989419]

Thu, 06 December 2012 08:13

Thomas Schindl

Messages: 6651
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.

Report message to a moderator

Previous Topic:	Tooltip on viewer item when using AdapterFactoryLabelProvider
Next Topic:	When does the system inject @Optional annotated fields?

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 26 08:54:51 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter