[ https://issues.jboss.org/browse/JBIDE-10702?page=com.atlassian.jira.plugi... ] Randall Hauch updated JBIDE-10702: ---------------------------------- Forum Reference: https://community.jboss.org/message/648276#648276 The idea for this feature came from a [post|https://community.jboss.org/message/648276#648276] on the ModeShape forums. -- 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

[ https://issues.jboss.org/browse/JBIDE-10702?page=com.atlassian.jira.plugi... ] Randall Hauch commented on JBIDE-10702: --------------------------------------- Per email conversation with Max: {quote} bq. So is this something that would be included in ModeShape Tools, or would this just be a completely separate Eclipse plugin that could be installed separately from everything else? The reason I ask is that I think a lot of Jackrabbit users would also find this very useful. both can be made possible. Modeshape module would just add a new eclipse feature (i.e. org.jboss.tools.modeshape.jcreditor.feature labeled 'JCR Editor' or similar) that only includes the editor bit's and the existing modeshape feature includes that feature. Then they can choose. {quote} This sounds perfect. -- 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

[ https://issues.jboss.org/browse/JBIDE-10702?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-10702: --------------------------------------------- setting fix version to something else than "nothing" Dan - want to set a target version or LATER ? -- 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

[ https://issues.jboss.org/browse/JBIDE-10702?page=com.atlassian.jira.plugi... ] Dan Florian commented on JBIDE-10702: ------------------------------------- Edited UI Mockup <NamespacesEditorTab>: The namespaces editor tab of the multi-tab CND editor. -- 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

[ https://issues.jboss.org/browse/JBIDE-10702?page=com.atlassian.jira.plugi... ] Dan Florian commented on JBIDE-10702: ------------------------------------- Edited UI Mockup <NodeTypesEditorTab>: Node Types Editor Tab of the multi-page CND form editor. -- 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

[ https://issues.jboss.org/browse/JBIDE-10702?page=com.atlassian.jira.plugi... ] Dan Florian commented on JBIDE-10702: ------------------------------------- Edited UI Mockup <NodeTypesEditorTab>: Minor change to node type attributes section. -- 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

[ https://issues.jboss.org/browse/JBIDE-10702?page=com.atlassian.jira.plugi... ] Dan Florian commented on JBIDE-10702: ------------------------------------- Edited UI Mockup <PropertyDefinitionDialog>: First draft of property definition editor dialog. -- 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

[ https://issues.jboss.org/browse/JBIDE-10702?page=com.atlassian.jira.plugi... ] Dan Florian commented on JBIDE-10702: ------------------------------------- Edited UI Mockup <NodeTypesEditorTab>: Added some icons. -- 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

[ https://issues.jboss.org/browse/JBIDE-10702?page=com.atlassian.jira.plugi... ] Dan Florian commented on JBIDE-10702: ------------------------------------- Edited UI Mockup <ChildNodeDefinitionDialog>: First draft of the "Child Node Definition Editor" dialog. -- 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

[ https://issues.jboss.org/browse/JBIDE-10702?page=com.atlassian.jira.plugi... ] Randall Hauch commented on JBIDE-10702: --------------------------------------- I just added an alternate straw-man mockup for the primary editor tab (other tab would show source). My goal with this was to see if we could minimize the number of dialogs/screens while maximizing the information visible to the user at any one time. Overall, it's not too different than Dan's mockups. Since the namespaces won't need to be visible most of the time, the "Namespaces" and the "Node Types" containers could be collapsable (see the Maven POM editor for example). This might not be needed, however, if there's sufficient real estate for the "Node Types" section. This design also includes in the Property Definitions and Child Node Definitions tables most of the details about the corresponding items. This will keep the user from having to double-click (i.e., edit) to just visualize some of the details. However, I'd be perfectly happy if no cells in the table were editable - simply double-click to edit via the dialog. As mentioned in the description, the "Show inherited" feature would be a really nice to have. -- 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

[ https://issues.jboss.org/browse/JBIDE-10702?page=com.atlassian.jira.plugi... ] Dan Florian commented on JBIDE-10702: ------------------------------------- Thanks for all the good comments Randall. I'm good with adding a collapsable namespaces section to the GUI editor tab. That means, instead of 3 tabs, there will now only be the 2 tabs (GUI editor & text editor). I had put namespaces on its own tab because I thought that would be a low-frequency/low-effort part of editing a CND and didn't want that being the first thing the user looked at. However, that section can start off collapsed if we want and won't take up much space when it is collapsed (I can limit the number of visible rows). It also keeps the GUI editor format in-line with the CND format. I'm also good with adding more detail to the property definitions and child node definitions tables. Double-clicks in the namespaces, property definitions, and child node definitions tables will display an dialog editor. I like the vertical orientation (one on top of the other) of the property definitions and child node definitions section. That will allow more of their data to be seen. However, I think extending those sections horizontally to the entire width of the editor would be even better. This would make the node types section not as tall (but don't think that is a bad thing). Seems like there is a lot of wasted space in the node types table if it extends to the full height of the editor. As far as variants go, I included that concept in the design because it is in the spec. I've already added that concept to the business objects I've created. If we truly want to be a JCR 2.0 CND editor I think we need to/should include this concept. I've made each attribute a set of 2 radio buttons, versus just a checkbox, to make it clear to the user what it means if that attribute is not selected and what the default value is. It still only "costs" the user one click. I will need to more information on the "Show inherited" feature. How will that work? How will the editor find the referenced node type definitions? Is the feature something that you want to go out with the first version of the editor or can it be added later? I also need more information on the CndTokenizer. I have moved that code over to the new plugins I've created. I have those new plugins dependent on the ModeShape client jar. Does the tokenizer fail on the first error it finds? Or does it just keep track of the errors as it tries parsing the input? Does the tokenizer return user-friendly error messages? How can I turn the tokenizer-created tokens into my business objects that the editor will use? -- 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

[ https://issues.jboss.org/browse/JBIDE-10702?page=com.atlassian.jira.plugi... ] Randall Hauch edited comment on JBIDE-10702 at 2/10/12 11:28 AM: ----------------------------------------------------------------- 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...], [this|https://github.com/ModeShape/modeshape/blob/3.x/modeshape-jcr/src/te...], [this|https://github.com/ModeShape/modeshape/blob/3.x/sequencers/modeshape...] and [this|https://github.com/ModeShape/modeshape/blob/3.x/sequencers/modeshape...] 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 suggested, 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/mode...] and [ChildNodeDefinitionId|https://github.com/ModeShape/modeshape/blob/3.x/mod...] 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. was (Author: rhauch): 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...], [this|https://github.com/ModeShape/modeshape/blob/3.x/modeshape-jcr/src/te...], [this|https://github.com/ModeShape/modeshape/blob/3.x/sequencers/modeshape...] and [this|https://github.com/ModeShape/modeshape/blob/3.x/sequencers/modeshape...] 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/mode...] and [ChildNodeDefinitionId|https://github.com/ModeShape/modeshape/blob/3.x/mod...] 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. -- 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

[ https://issues.jboss.org/browse/JBIDE-10702?page=com.atlassian.jira.plugi... ] Randall Hauch commented on JBIDE-10702: --------------------------------------- These look really good. The only one I can think of is the error when a token doesn't match the Property Definition and Child Node Definition attributes: ERROR - Invalid or unknown attribute 'x' If possible, the message might even suggest one (or all) of the attributes, so something like "Did you mean 'y'?" Not a big priority, though. -- 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

[ 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. -- 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

[ https://issues.jboss.org/browse/JBIDE-10702?page=com.atlassian.jira.plugi... ] Randall Hauch edited comment on JBIDE-10702 at 2/29/12 5:06 PM: ---------------------------------------------------------------- BTW, none of the Jackrabbit test files ([here|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-core/src/...] and [here|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-spi-commo...]) contain any '?' characters. And its [CompactNodeTypeDefReader.java|https://github.com/apache/jackrabbit/blob/t...] class says it supports '?' in the JavaDoc, but doesn't actually appear to do anything with them. The older [Jackrabbit wiki page|http://jackrabbit.apache.org/node-type-notation.html] that talks about the CND format doesn't even have the notion of variants. IMO, this helps support my submission that the variants are only useful within the spec, that any real CND files processed by an implementation will never need or use variants, and therefore the CND editor's UI shouldn't even expose the notion of variants. was (Author: rhauch): BTW, none of the Jackrabbit test files ([here|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-core/src/...] and [here|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-spi-commo...]) contain any '?' characters. And its [CompactNodeTypeDefReader.java|https://github.com/apache/jackrabbit/blob/t...] class says it supports '?' in the JavaDoc, but doesn't actually appear to do anything with them. IMO, this helps support my submission that the variants are only useful within the spec, that any real CND files processed by an implementation will never need or use variants, and therefore the CND editor's UI shouldn't even expose the notion of variants. -- 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

[ https://issues.jboss.org/browse/JBIDE-10702?page=com.atlassian.jira.plugi... ] Pavol Srna closed JBIDE-10702. ------------------------------ Basic functionality of CND editor verified. -- 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