[jbosstools-issues] [JBoss JIRA] (JBIDE-10702) Editor for JCR Compact Node Definition (CND) files

[Randall Hauch (JIRA)]

    [ https://issues.jboss.org/browse/JBIDE-10702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665698#comment-12665698 ] 

Randall Hauch commented on JBIDE-10702:
---------------------------------------

Regarding the namespace section: I completely agree that namespace editing is a low-frequency activity, and a separate tab is a good idea. My *only* (pretty minor) concern about putting it on a separate tab was that it might be harder for people to find when initially learning the editor. That's not much of an argument for no separate tab, though.

Regarding the vertical orientation: There will likely be a lot of node types, so having a short table might require a fair amount of scrolling or filtering (see [this|https://github.com/ModeShape/modeshape/blob/3.x/sequencers/modeshape-sequencer-ddl/src/main/resources/org/modeshape/sequencer/ddl/StandardDdl.cnd], [this|https://github.com/ModeShape/modeshape/blob/3.x/modeshape-jcr/src/test/resources/cnd/teiid.cnd], [this|https://github.com/ModeShape/modeshape/blob/3.x/sequencers/modeshape-sequencer-wsdl/src/main/resources/org/modeshape/sequencer/wsdl/wsdl.cnd] and [this|https://github.com/ModeShape/modeshape/blob/3.x/sequencers/modeshape-sequencer-xsd/src/main/resources/org/modeshape/sequencer/xsd/xsd.cnd] CND examples). Additionally, everything on the right of the vertical divider is based upon the selection of a node type on the left, and I thought the longer node type table helped make this more obvious. 

As you suggestion, the downside of this is that the property definitions table and child node definitions table are a bit narrower. But no matter how wide the tables are, they won't be able to show everything about each property definition or child node definition. For example, constraints might simply be too long to practically fit. IMO, the goal should be to provide as much info as possible, namely the names, types, and attributes; these won't take up that much space. Thus, the best compromise -- showing the list of types and enough of the property & child node definitions -- will be the most usable IMO.

Regarding "show inherited": this does not need to be in the first version, but it's pretty simple. It simply involves showing the property definitions (or child node definitions) for each of the declared supertypes (and their supertypes). It might be necessary (for performance/validation) to keep track of property definition and child node definitions by an identifier (e.g., it would help determine whether two property definitions are invalid if they have the same identifier; see ModeShape's [PropertyDefinitionId|https://github.com/ModeShape/modeshape/blob/3.x/modeshape-jcr/src/main/java/org/modeshape/jcr/PropertyDefinitionId.java] and [ChildNodeDefinitionId|https://github.com/ModeShape/modeshape/blob/3.x/modeshape-jcr/src/main/java/org/modeshape/jcr/NodeDefinitionId.java] classes, which properly implement the spec behavior.

The radio buttons are okay, but they seem noisy and the two options aren't really very different. E.g., "Protected" vs "Not Protected", "Query Orderable" vs "Not Query Orderable", etc. Anything to make the view less complex is a good thing. Plus, there is some duplication of information: the "Query Operators" could just be the list of checkboxes for each operator; check them all if all operators are to be supported. Also, I think the OPV should just be a choice box that defaults to COPY.

Be sure you've taken the CndTokenizer and CndImporter (which is really a parser) from the '3.x' branch. You probably want to use the CndImporter -- or at least look and see how the tokenizer is used.
                
> Editor for JCR Compact Node Definition (CND) files
> --------------------------------------------------
>
>                 Key: JBIDE-10702
>                 URL: https://issues.jboss.org/browse/JBIDE-10702
>             Project: Tools (JBoss Tools)
>          Issue Type: Feature Request
>          Components: modeshape
>            Reporter: Randall Hauch
>            Assignee: Dan Florian
>             Fix For: 3.3.x, 3.4.x
>
>         Attachments: Alternate Editor Tab Strawman (RMH).bmml, Alternate Editor Tab Strawman (RMH).png, ChildNodeDefinitionDialog.bmml, ChildNodeDefinitionDialog.bmml, ChildNodeDefinitionDialog.bmml, ChildNodeDefinitionDialog.png, NamespacesEditorTab.bmml, NamespacesEditorTab.bmml, NamespacesEditorTab.png, NodeTypesEditorTab.bmml, NodeTypesEditorTab.bmml, NodeTypesEditorTab.bmml, NodeTypesEditorTab.bmml, NodeTypesEditorTab.bmml, NodeTypesEditorTab.bmml, NodeTypesEditorTab.bmml, NodeTypesEditorTab.bmml, NodeTypesEditorTab.bmml, NodeTypesEditorTab.bmml, NodeTypesEditorTab.bmml, NodeTypesEditorTab.png, PropertyDefinitionDialog.bmml, PropertyDefinitionDialog.bmml, PropertyDefinitionDialog.bmml, PropertyDefinitionDialog.bmml, PropertyDefinitionDialog.bmml, PropertyDefinitionDialog.bmml, PropertyDefinitionDialog.bmml, PropertyDefinitionDialog.png
>
>
> JSR-283 (aka, JCR 2.0) includes a standard format called 'Compact Node Definition' that is used to declare node types, property definitions, and child node definitions. 
> *Resources*
> The official grammar of the CND format is defined in [Section 25.2|http://www.day.com/specs/jcr/2.0/25_Appendix.html#25.2%20Compact%20Node%20Type%20Definition%20Notation] of the JCR 2.0 specification. The ModeShape project has in its documentation a [tutorial|https://docs.jboss.org/author/display/MODE/Defining+custom+node+types] for working with CND files.
> The ModeShape project also has code to parse a CND file, and it's probably better to simply copy this code and simplify/customize it to the editor's needs rather than have the editor depend on the ModeShape project for just these classes (which probably aren't perfectly usable as is for the editor).
> There are also example CNDs in the ModeShape codebase.
> *Requirements*
> # Edit any .cnd file in the workspace _(Priority 1)_
> # View the file source, with support for select/copy _(Priority 1)_
> # Edit the file source, with support for paste _(Priority 3)_
> # Syntax highlighting (color keywords, quoted strings, comments) of file source would be a nice-to-have _(Priority 2)_
> # Problem markers (in file source, Problems view) would be a nice-to-have _(Priority 3)_
> # Form-based editor:
> ## view/edit/add/remove namespace declarations _(Priority 1)_
> ## view/edit/add/remove node type and its attributes and supertypes _(Priority 1)_
> ## view/edit/add/remove property definition (and its attributes) for a selected node type _(Priority 1)_
> ## view/edit/add/remove child node definition (and its attributes) for a selected node type _(Priority 1)_
> # Preferences for
> ## using long, medium, or short forms of attributes (e.g., "abstract" vs "abs" vs "a") _(Priority 2, start out w/ long)_
> *Other ideas*
> # It would be nice if the user doesn't have to scroll in the form editor when working on a node type.
> # Is it possible to optionally see the both inherited and explicit property definitions and child node definitions? Perhaps the inherited definitions might be grey-ed out and non-editable. One issue might be how to know which node type it came from (without cluttering up the UI).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira