Skip to main content

[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

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));
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" />

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/>…]


On 31-Jan-2012, at 3:22 PM, Tom Schindl wrote:

> Hi Lars,
> I'm not 100% I really understand what you are suggesting here? Is that
> the tooling generates constants in an extra class?
> I'm also not sure what the URL modelid:// is good for? Did you e.g. know
> that you can simply use XPath on EMF-Models (we don't ship the bundle
> but it's part of the e4-git-repo).
> I think you need to elaborate a bit more, so that I can understand what
> you propose and how it could be implemented.
> Tom
> Am 30.01.12 23:12, schrieb Lars Vogel:
>> Hi,
>> one thing I like about Android programming, is that you can refer to
>> static strings for ID's in a XML file (layout file) as well as in Java
>> code. In the layout file you use @id/button1to point to a ID defined in
>> a file.
>> In your Android coding you could reference the ID via a static string.
>> This removes the issue that you may have typos either in your coding or
>> in your layout and allows consistent refactoring of ID's.
>> One of the issues I believe still exists in todays Eclipse 4 plug-in
>> development, is that you have to define a ID twice, once in your
>> application model and at least once in your coding.
>> I really liked the change to bundleclass:// in M5. 
>> Perhaps we could introduce another URI for ID which could be referred to
>> an ID defined in a file, e.g. 
>> modelid://Bundle-SymbolicName/path/filename.extension/id
>> And add another annotation, like @ID, which allows to annotate static
>> strings and to mark them a ID's which could be used in the model as well
>> in the coding.
>> @ID
>> public static final String part1 = "com.example.test.part1".
>> Would that be helpful? Is it worth to open a enhancement request for this?
>> Best regards, Lars
>> -- 
>> Lars
>> - Eclipse, Android and Java Tutorials
>> - Lars on Twitter
>> _______________________________________________
>> e4-dev mailing list
>> e4-dev@xxxxxxxxxxx
> -- 
> 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
>                      phone    ++43 512 935834
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx

Back to the top