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

Wed Feb 29 16:57:36 EST 2012

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

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

I don't think the UI (or text editor, for that matter) needs to support the '?' token used to specify variants. The JSR-283 spec isn't very clear on it, but it appears that the CND grammar has them because of the following reasons:

§25.2 states:

{quote}
defines the compact node type definition (CND) notation used to define node types throughout this specification
{quote}

Section 25.2.2 states:

{quote}
In a CND _[within the spec?]_, the presence of a question mark ("?") indicates that an attribute in question can vary across repository implementations (see §3.7.10 Base Primary Node Type and 3.7.11 Standard Application Node Types).
{quote}

and

{quote}
Such variant node type definitions cannot be instantiated in a repository as-is. If an implementation supports a variant node type its node type registry must contain a definition of that node type in which each variant attribute is resolved to a concrete value.
{quote}

Section 3.7.9.1 talks about the CNDs defined in the spec:

{quote}
Some of the attributes of the node types defined in this specification may vary across implementations. For example, it is implementation-dependent which node types and which properties are queryable (see §3.7.1.5 Queryable Node and §3.7.3.3 Available Query Operators). Similarly, some of the standard application node types (see §3.7.11 Standard Application Node Types) may vary as to the on-parent-version and protected status of some properties. In the CND notation, variant attributes are indicated with either a question mark (for example, {{protected?}} and {{opt?}}) or, in the case of the queryable node type attribute, by the absence of an explicit indicator. For the queryable attribute of a node type to be non-variant it must be explicitly defined using the keywords query or noquery, (see §25.2 Compact Node Type Definition Notation).
{quote}

If I'm reading that right, the implementation can choose which of the values of a variant attribute the implementation  wants to use. That choice can't really be done while loading _any_ CND file; rather, the implementation developers would decide that when specifying the implementation's built-in types.

Then there's Section 3.7.16 "JCR Node Type Variants", which states:

{quote}
An implementation may provide a variant of a JCR node type as a built-in under certain conditions.
{quote}

and then proceeds to describe how an implementation can alter the variant attributes (denoted with a '?') with a value attribute. For example, '{{mix:created}}' lists '{{jcr:createdBy}}' as "{{protected?}}", but that means an implementation can either make '{{jcr:createdBy}}' definition either "{{protected}}" or not "{{protected}}", but not both (or either-or).

In summary, I think the UI does not need to expose variants at all. It may be useful to read the '?' characters in, but it may as well immediately remove them.

> 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