| Summary: | Add ability to auto-generate model element IDs | ||
|---|---|---|---|
| Product: | [Eclipse Project] e4 | Reporter: | Matthias Basler <matthiasbasler> |
| Component: | UI | Assignee: | Project Inbox <e4.ui-inbox> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
Sorry, just noticed that there exists already a possibility to turn ID auto-generation on in the Eclipse preferences. It is equivalent to what i suggested as schema "{plugin-name}.{types}.###".
There's currently (4.1M4) an issue, which is that the preference page always shows the checkbox toggled "off", even if auto-generation was turned on.
But since the original request is already fulfilled in some way, I will close this issue myself.
|
Build Identifier: I20101216-1305 When building a UI model with the Workbenchmodel editor, a lot of UI elements are created: Handlers, commands, menus, toolbars, toolbar items a.s.o. Several (seemingly not all) of these require IDs order ot be referenced within the model (e.g. Commands) or in order to be extendable by model fragments (e.g. menus) The user therefore has to "invent" a lot of internal IDs. If they could be created automatically after some consistent "best practice" schema this would have some benefits: - Saving the developer time and the need to come up with his/her own schema. - Consistency in naming. - Avoiding problems like trying to contribute to an element that got no ID. The default schema could be {Type}:{plugin-name}.{Type}### (with ### being a sequential number), e.g. menu:org.test.e4application.menu1 or handler:org.test.e4application.handler5 or {plugin-name}.{types}.###, e.g. org.test.e4application.menus.1 org.test.e4application.handlers.5 In some cases it might even be possible to infer a reasonable name instead the number the item's label, e.g. org.test.e4application.menus.file (for a menu called "File") or org.test.e4application.commands.say_hello (for a command labelled "Say hello") Of course the user must be able to override the auto-generated ID, and it should then not be overwritten any more. Opinions? Reproducible: Always Steps to Reproduce: Does not apply.