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 ;-)
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.
(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?).
Yes, JIRA is good for new feature requests as well.
http://www.jcr-explorer.org/screenshots.html
(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
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.
Yes, a good access to versions and a proper visualization would be
great!
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.
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/controls/HierBrows.htm
But you should always also provide the standard tree view, cause
that's what most developers are used to.
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.
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.
Regards,
Alex
--
Alexander Klimetschek
[EMAIL PROTECTED]
>> Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/ <<
