template-dialog-tree-reorganization - The template dialog must be sorted in order to improve templates' usability.

[todor]

• The items in the template dialog must be organized according to some criteria in order to improve template's usability.
  • The tree structure can be rearranged this way:

Frame
|_Use as a default template
|_Content
| |_Main resource
| |_Controls visibility*
| |_Loop*
| |_Browser URL*
| |_Chaining mode*
|_Appearance
| |_Wrapping mode
| |_Background
| | |_Color
| | |_Type
| | |_Gradient
| | |_Image
| | |_Opacity
| | |_Pattern options
| |_Shadow
| |_Enabled
| |_Opacity
| |_Position
| |_Color
|_Properties
| |_Frame visibility
| |_Size
| |_Location
| |_Orientation
| |_Links
| |_Timeline options
| |_Insets
| |_Margin
| |_Padding
|_Other

• Frame specific features

• For now the Other entry is reserved for possible future keys

• The selection behavior is the same as the one described in #2394
• For other levels the structure is analogical

Page
|_Content
| |_Group A
| | |_Frame A
| | |_Frame B
| |_Appearance
| |_Properties
| |_Other
|_Appearance
|_Properties
|_Other

• (optional) Some of the entry names are not enough explanatory, you can rename them as it's shown above.

[boyanl]

The description is clear and sufficient.

[boyanl]

• Add an @interface Category for the annotation marking the category for each key, which is constructed from a String. It can be placed above a field, or a class (so all of its fields are considered annotated with this category).
• Add an inner class Categories containing pre-defined names for the categories (to avoid duplication and misspelling).
• Add a static method in ResourceR4 that gets the keys annotated with @Category in a given class (and its superclasses/interfaces).
• Rename TemplateDialog to CreateTemplateDialog.
• Modify the dialog logic in the CreateTemplateDialog class to add category nodes to the tree too.
• Modify some logic in the CreateTemplateDialog.CheckBoxTree.CheckNode to avoid code duplication and to handle deletion of children nodes.
• Extract the "Use as a default template" node as a checkbox outside of the tree.

[meddle]

• Don't forget that the annotations must be 'Runtime' ones.
• Don't put the method getting the keys in ResourceR4. This is more view related feature, use the ResourceH class for that.
  • Don't write such complex logic, ResourceR4 has methods for retrieving all the keys of a resource, use it, it is already written, then filter all the keys that are annotated.
  • If I was you, I would add a method getKeys(KeyFilter, Class<? extends ResourceR4>) in ResourceR4, that gets all the keys from a resource by a given filter (write such interface yourself and write filter that checks for the category annotation)...
  • Other thing is to write similar method that returns all the keys grouped by some categories (with special KeyCategoryFilter) in a map, and call this method with the right category filter form ResourceH... You decide, I give you some reusable ideas, but if you add such methods, I want ModelUnitTests!
• Also... Make a branch, deleting stuff with patch is buggy (renaming = delete + create), I told you this last time...

3.5p

[boyanl]

Made some further changes:

• Removed getCategorizedKeys in ResourceR4 and instead added a method getKeys(KeyFilter keyFilter, Class<? extends ResourceR4> resourceClass. The KeyFilter interface has one method boolean acceptKey(Field field, Class<?> declaringClass, where field is the field corresponding to the key and declaringClass is the class this field was declared in.
• Added a method getCategorizedKeys in the ResourceH class, which fetches all the keys annotated with the Category annotation, it uses the getKeys method described above.
• Added a testing class (ResourceR4Test) for ResourceR4 (which currently just tests the functinality of getKeys)

The changes are in [9074].

[meddle]

Merged into the trunk at [9095].

• A lot of malformed/fake JavaDoc in Category and KeyFilter.
• Place the curly brackets on the same row as the class definition.
• Don't write in the JavaDoc links as {@link: Something} it does not become link in the html. The right syntax is {@link Something} and for methods {@link: #Something}.
• Write inlined in methods class declarations only if you are sure the class will be used only in the method... For your filter, I am not sure (for the future), so I converted it to nested.

[meddle]

Closing all the tickets before M Y1