3:57 p.m.
[
https://issues.jboss.org/browse/JBIDE-10702?page=com.atlassian.jira.plugi...
]
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%20N...]
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+...] 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