> Hi! > > Am 23.04.2008 um 17:26 schrieb Craig L. Ching: > > 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 find it useful, like in the Windows Explorer. You see both folder > and files (comparing nodes to folders and properties to files here). > This way you see all the children of the node in one place. The JCR > API somewhat supports this by having "Node" and "Property" inherit > from the base interface "Item". In addition, a node type definition > defines both child nodes and properties for a node - another reason > for putting it together. > > Anyway, it's my personal opinion here. We need more opinions or even a > usability test to find out what is the best ;-) > Sure, let me think about it. I'm planning on a mock-up for review "soonish."
> > 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??)." > > Hmm, I think tabs are not perfect here. What if you want to do an > operation (found in the tab "Operations") on a property (found in the > tab "Properties")? They cannot be visible at the same time. > Could you give me an example? I'm not an expert on JCR, but I can't think of an operation that you can perform on a property, I thought you could only change its value. It's possible we could distinguish property operations which could be on this tab from node operations which would be on the "Operations" tab (maybe renaming it to "Node Operations" if needed). For instance, if you look on the JCR Explorer screen shot, I don't see anything that would indicate a property operation unless the green "+" signs do. And, if they do, we could do that on the "Properties" pane. I'm trying hard not to look too much at JCR explorer, especially for the UI, but it is useful to get an idea of what needs to be done generally. > > (the Main Panel one, btw, any idea what the "MA MU PR AU" stuff is?). > > Not 100% sure, but I am guessing: > > MA = Mandatory > MU = Multi-valued property > PR = Protected > AU = Auto-created > > See also Jackrabbit's documentation on node types: > > http://jackrabbit.apache.org/node-types.html > http://jackrabbit.apache.org/node-type-notation.html > Great, thanks! > > 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. > > Cool. > > Let me generalize: keyboard-only control would be very cool. For > example, I find it much more efficient and quicker to navigate the > tree with the keyboard ("left" goes to parent or closes it, "right" > shows the children). Unfortunately I haven't seen that often in web- > based tree views. > Oh, I'm going to do my damndest to get full keyboard controls ;-) I'm pretty sure dojo has good support for keyboard controls, but it's something I haven't myself investigated fully yet. > > 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) ... > > Not sure if you mean this, but this is one of the useful views in Mac > Finder: > > http://www.sapdesignguild.org/community/book_people/visualization/contro ls > /HierBrows.htm > Yeah, but without all the columns, just one column for children. IMO, this is a "nice to have" and won't be anywhere near my primary focus for now. > > 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). > > JCR 1.0 standardizes SQL and XPath Queries, where the XPath queries > are probably more popular, as they fit the nature of a tree structure > better. > > As Bertrand has already noted, it would be cool if the search results > would be in the same view as the normal tree. Not in another dialog or > something like that. > Yes, that's my thinking too. As for Xpath and SQL, sounds good. I thought I read xpath at one point, but my quick glance today hadn't turned it up ;-P I can't see why both couldn't be supported with little effort. > > 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. > > Custom property editors based on node types + property defintions > (especially for STRING and BINARY properties, eg. upload images, > render XML or source code in the browser etc.) are probably simpler to > start with. Custom node editors seem to be very complex to me and > would actually replace more than half of the explorer interface. > Yes, agreed. My idea here was to provide something along the lines of a CMS, something I'm ultimately interested in using sling for. This idea is definitely a "blue sky" type of idea, but I just wanted to get it on the table ;-) > Regards, > Alex > Thanks for the input! I have a lot to go on now! Cheers, Craig
