Re: [e4-dev] HandledItem Questions

[Boris Bokowski <Boris_Bokowski@xxxxxxxxxx>]

The idea was to have one (DirectMenuItem) that was as simple as possible, with no requirement to match IDs or link to existing framework objects. This is for the case where you just want a menu or toolbar item that does something, and all you should have to do is point to a class that implements the execute() method with the behaviour you want.

The other one (HandledMenuItem) is meant for the more complex cases, where you'd like to be able to bind keys to a command and have the key binding appear in the menu, or where you may have multiple menu or toolbar items for the same command, or multiple handlers for the same command. In this case, I prefer direct EMF references to the "other" model objects over matching by ID or URL - the latter is a common problem in Eclipse 3.x where you wonder why something is not working for hours until you discover that some ID didn't match some other ID.

If we can keep the straightforwardness and simplicity of the first option, but combine both into one type, that would probably an improvement.

I wrote this in a hurry but hope that it nevertheless made some sense.

Boris


Olivier Moïses ---03/07/2010 10:32:51 AM---Hi all, Why do we need a difference between HandledMenuItem and DirectMenuItem ?

From:	Olivier Moïses <olivier@xxxxxxxxxxxxxxxxxxx>
To:	E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
Date:	03/07/2010 10:32 AM
Subject:	Re: [e4-dev] HandledItem Questions
Sent by:	e4-dev-bounces@xxxxxxxxxxx

---

Hi all,

Why do we need a difference between HandledMenuItem and DirectMenuItem ?
Ok, there is two different mechanisms, the first one uses a reference to the command and the second uses contribution.

But, we could merge by using URIs in both cases :
We could keep the existing URI based contribution (platform:/plugin/org.eclipse.e4.demo.contacts/org.eclipse.e4.demo.contacts.handlers.ExitHandler)
For former HandledMenuItem, we could use 'urn:command:command_id'

This approach makes it possible to provide a metamodel where the user adds by its nature and not by how it will be related to execution. 
Another benefit is that we will divide by two the number of required classes in metamodel for building our toolbars and menus :-D


Regards,

Olivier


2010/3/7 Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>

Would my proposal in the other reply give us the best of both worlds?

If one has access to the command instance one uses a CommandItem else a
ReferencedCommandItem, if you add an EOperation to acccess the command
the framework itself doesn't even have to deal with the difference how
the Command-Instance is retrieved.

I think that in a world made up of contributions I can't access a
Command-EObject defined e.g. by the workbench, ... in my ModelComponent.

Say I want to invoke a Command-Contributed by JDT? How would you allow
me to invoke it in the current implementation?

Tom

Am 07.03.10 13:59, schrieb Paul Webster:
> On Sun, Mar 7, 2010 at 5:44 AM, Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx> wrote:
>> Hi,
>> I think a HandledItem needs to hold the command-id it wants to call and
>> not the Command-Instance itself.
>
> it's like that because "in theory" you can't define a HandledMenuItem
> or HandledToolItem without a command.  If we make it an ID then we
> have to do reference checking everywhere we use it in the app.  We
> also have to maintain the lookup to get the command every time we need
> it.
>
> But since that's what we've always done, I don't think it's a big deal
> if you want to change it from a reference to simply an ID.
>
> PW
>
>


--
B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl                                        geschaeftsfuehrer/CEO
------------------------------------------------------------------------
eduard-bodem-gasse 5/1    A-6020 innsbruck      phone    ++43 512 935834
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev

_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev