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 have little experience in E4, but I follow this mailing list for some time to see what's coming up.

I have some remarks about the feature discussed here : if we define the IDs in the implementing classes and just make references to them from the model, won't it become harder for third-party plugins or features to plug against an application ? Actually we just need the model (the xmi file) to lookup ids of model elements, but introducing these "identifier URLs" I guess we would need to look into classes. Isn't the key of modularity and extensibility to keep the identifiers in the xmi model ? Maybe i'm totally wrong and missed something, or perhaps should we use "hard" ids in the model for elements we want to expose for possible extension, and use id URLs for
internal stuff.
Please let me know,

Thanks for the great job you are all performing on e4,

Le 31/01/2012 21:16, Tom Schindl a écrit :
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!


Back to the top