Community
Participate
Working Groups
Problems: (1) Nobody understands what these fields are for (2) These fields make the details section of elements more cluttered (3) The fields only affect the presentation of elements in the manifest editor Extensions tree viewer (icon and name) -> This should be calculated dynamically rather than having to specified manually Criteria: For the element's presentation name, the element's first translatable attribute of type string should be used. For the element's presentation icon, the element's first attribute of type resource should be used. Recommendation: I think the easiest and cleanest way to do this is to update the element's schema annotation everytime a new attribute is added (in the schema editor) only if a value has not already been specified: <appInfo> <meta.element labelAttribute="name" icon="icon"/> </appInfo> Care has to be taken to preserve values already specified that do not meet the specified criteria above.
Mike, can you take a look at bug 195764?
Created attachment 74163 [details] patch The fields have been removed. The modelChanged method in AbstractSchemaDetails has been updated to validate and generate the properties if necessary. If the specified attributes become invalid and no suitable replacements are found, the properties are set to null. This will result in the defaults being used, which is the same behaviour as if the fields were left blank previous to this change.
Created attachment 74196 [details] patch This is a much better implementation. If the properties are specified in the schema file, they are persisted and used. The "guessed" properties are not written to the schema, however. Instead, the SchemaAttribute.getLabelProperty() and SchemaAttribute.getIconProperty() will simply return the guessed values in the case that the requested property is null.
Brilliant! Thanks Adam.
