Hi Alex, I was thinking about what you said here:
> IMHO there should be 3 main panes: the tree (to the left), containing > only nodes, a property + child node list and a third pane below with > node type / property type definitions and other node metadata. > Basically like the Windows explorer with an open folder view on the > left. This is just a personal opinion, though. > I have a question for you, why do you want the children in a separate pane when they will also be in the tree? I'm actually thinking of keeping all nodes just in the tree (and expandable if they have children) with a tabbed pane on the right. The tabs would be "Properties", "Operations", "(Others??)." The "Properties" tab would, of course, show you the properties for the currently selected node and allow you to edit the properties (NOTE: I'd like the PropertyType exposed in the JSON so the UI can determine the type of "editor" to use (e.g. combo box for boolean, text box for string, etc.), open a JIRA for that?). The "Operations" tab would allow you to do things like add a new property to the node, add a new child to the node, export the node (optionally recursively), etc. So far a lot of what I'm thinking is realized in this screenshot which I'm sure you've all seen: http://www.jcr-explorer.org/screenshots.html (the Main Panel one, btw, any idea what the "MA MU PR AU" stuff is?). I'm not sure yet what I think of the "Lock" tab they have (kind of seems to me that that might be part of the "Operations" tab), but the versions tab would probably be pretty useful. Some other general ideas I have 1) A "path" text box where you can simply type the path to the node and the tree will respond/expand appropriately. The text box would also present valid completions, e.g. as you type /dojo/, a drop down list would show the children that could complete that. 1a) I *might* experiment with a different sort of tree navigator that I've been thinking about implementing in dojo, but haven't had the time yet. It's sort of like the Vista explorer (which I'm sure is a rip-off of some mac concept, the finder or whatever), you have a "bread crumb" trail at the top and the children of the current node indicated in the breadcrumb trail are simply listed (not in a tree like the vista explorer, just a list) in a list view. To go to a child, you can either type in the box, or click the child in the list. This may be a bit "out there" for people, but I think it's better than a tree because you don't get the horizontal real-estate problems that you can get with a deep tree. It's possible this could be an optional means of navigation and we provide the tree if people are not comfortable with it. 2) A search box that allows SQL queries (are there any other type of queries? I seem to recall there are, but I just went back and glanced at the JSR-170 spec and didn't see any others besides SQL). 3) Customizable editors. I don't have any concrete ideas here, but I was thinking we could keep a mapping of the primary node type to an editor somewhere and instantiate the editor when it's needed. This way users could write editors for their content and we could just invoke them in the repository browser when needed. > Alex > > -- Cheers, Craig
