[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[List Home]
|
Re: [e4-dev] Improved handling of ID's - Suggestion for discussion
|
- From: Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>
- Date: Tue, 31 Jan 2012 22:16:26 +0100
- Delivered-to: e4-dev@eclipse.org
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bestsolution.at; h=content-transfer-encoding:content-type:content-type :in-reply-to:references:subject:subject:mime-version:user-agent :from:from:date:date:message-id:received:received; s=default; t= 1328044587; x=1329858987; bh=reel5UrmjqrK7KfzOxT8ayfHJJ7HxJ2Hj+0 6+YaUhgc=; b=WQ0Zd65AvnD36DBblORLuPKiH1aOpYnSOKxRNAclsZGBGO8ATql LJeK4vpmVK69UK1FblrmoJSspeqTAPA9lLHOQWhd9snAm4Mb8wIawVT1T1qyJtdn 1gz+AwjjXF8iK5mKGxsqhBReAScwuh+KHS6Yf+hI9AiQsEssOoK0aSDw=
- User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
Am 31.01.12 22:03, schrieb Brian de Alwis:
> I think an example of what Lars is talking about is to allow referencing an identifier from within a .e4xmi file that is actually defined in source code. This would allow single-sourcing of an identifier.
>
> For example, say we have a command defined for org.eclipse.ui.exit, and some code that wants to programmatically execute this command. Currently we'd define the command in an e4xmi file:
>
> <commands elementId="org.eclipse.ui.exit" />
>
> And then also reference the command identifier from a source file:
>
> public class MyPart {
> public static final String EXIT_ID = "org.eclipse.ui.exit";
>
> // does this work?
> @Inject @Named(EXIT_ID) MCommand exitCommand;
> @Inject EHandlerService hs;
>
> public void executeExit() {
> hs.executeHandler(new ParameterizedCommand(exitCommand, null));
> }
> }
>
Ok that make sense but I guess this should read @ModelId() instead of
name, not?
> Currently, org.eclipse.ui.exit has to be used both in the .e4xmi file defining the command, and in the code.
>
> Lars' suggestion would change the e4xmi to something like:
>
> <commands elementId="model://bundle/MyPart/EXIT_ID" />
>
Ok I see.
> That would cause the command's elementId to be looked up (and validated!) at runtime; mismatches could be reported. (I guess either ApplicationElementImpl#[gs]etElementId() would need to hook in some resolver.)
>
> But I see one possible problem: what should happen if the bundle is unloaded or replaced — and the identifier is now different? I suppose since almost all objects now use references, it may only be an issue with fragment's imports.
>
> [Incidentally, why is it that the e4xmi elements are plural? <commands/>, <handlers/>, <bindings/>, <addons/>…]
>
It's the name of the feature!
Tom
--
B e s t S o l u t i o n . a t EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl geschäftsführer/CEO
------------------------------------------------------------------------
eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833
http://www.BestSolution.at phone ++43 512 935834