You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by David Nuescheler <da...@day.com> on 2008/04/22 17:01:10 UTC
JCR Explorer
hi craig,
personally, i think that it would be great if the jcr explorer was backed on the
standard sling json serialization and the standard forms conventions for
writing content.
i have recently seen a great example of a very good jcr explorer using
extjs. as a matter of fact i think that this was visually
substantially superior to the
dojo/swing based jcr explorers that i have seen in the past.
i think it may well be worth the effort of looking into finding out what we
can do around the gplv3 licensing of extjs.
just my two cents... ;)
regards,
david
On Tue, Apr 22, 2008 at 4:37 PM, Craig L. Ching <cc...@mqsoftware.com> wrote:
> I'll take a shot at the JCR explorer. My time is very limited, but I'll
> try and get a start this weekend. Is there a JIRA with some good
> requirements yet?
>
>
>
> > -----Original Message-----
> > From: bdelacretaz@gmail.com [mailto:bdelacretaz@gmail.com] On Behalf
> Of
> > Bertrand Delacretaz
> > Sent: Tuesday, April 22, 2008 5:15 AM
> > To: sling-dev@incubator.apache.org
> > Subject: Re: Welcome Janandith, let's make Scala happen for Sling
> during
> > GSoc!
> >
> > On Tue, Apr 22, 2008 at 12:08 PM, Vidar Ramdal <vi...@idium.no> wrote:
> >
> > > ... I guess this means that the JCR Explorer project was
> declined?...
> >
> > Yes, unfortunately that won't happen, and there was another project
> > about creating more tests (yum ;-) which won't happen either as part
> > of GSoC. We're lucky, and very grateful to Google and everyone
> > involved, to get one slot!
> >
> > And nothing prevents the other projects from happening, it's just that
> > they won't happen within GSoC this time.
> >
> > -Bertrand
>
--
Visit: http://dev.day.com/ - Day JCR Cup 08 - Win a MacBook Pro
RE: JCR Explorer
Posted by "Craig L. Ching" <cc...@mqsoftware.com>.
> well, i would agree to that... as long as we can agree that "looks"
> specifically
> visual consistency is important for a ui.
>
Looks and visual consistency are certainly important, but I will argue
that usability trumps both. Not that you can't get all of those with
dojo or ext, but I prefer to work in dojo as I said. Ext is not
something I'm interested in.
> > I am genuinely interested in your opinion and examples, though,
because
> > I've seen some really good dojo-based UI's.
> > I do think that the default L&F of dojo maybe isn't the best, but
I'm
> certain
> > we wouldn't have to live with that.
> well, maybe i just have only seen the wrong dojo ui's so far... maybe
> you could point me to a couple of good examples or themes that you
> think work with from a visual perspective.
>
Well, I did ask first about this great-looking ext-based JCR explorer
;-)
> and i guess visual consistency comes amongst other things from about
> a zillion small css settings that i am personally not prepared to put
in
> my time to fix them in dojo. i know that for myself, that i would then
> probably live with ugly interface and hate it every time i use it ;)
> (jokingly i would compare it to using fvwm on linux)
>
I would argue your assertion that changing css settings "fixes" dojo
because I don't view dojo as "broken" in the first place. It may not be
pleasing to you, but customizing css is just something that is necessary
to get a unique L&F and dojo is very css-aware, so that makes it easy.
What maybe isn't so easy are the graphical arts assets that you need to
make it so. I'm not sure I have the talent in that area, but I do have
a couple of resources I can potentially pull from.
> regards,
> david
Re: JCR Explorer
Posted by David Nuescheler <da...@day.com>.
> Personally, I prefer dojo and would rather contribute something based on
> that. If people want to do an ext-based explorer, I'm not sure that's
> something I'd be interested in. As for looks, I'd need you to be more
> specific about how ext is "visually substantially superior." Honestly,
> though, there is more to javascript UI development than just looks ;-)
well, i would agree to that... as long as we can agree that "looks" specifically
visual consistency is important for a ui.
> I am genuinely interested in your opinion and examples, though, because
> I've seen some really good dojo-based UI's.
> I do think that the default L&F of dojo maybe isn't the best, but I'm certain
> we wouldn't have to live with that.
well, maybe i just have only seen the wrong dojo ui's so far... maybe
you could point me to a couple of good examples or themes that you
think work with from a visual perspective.
and i guess visual consistency comes amongst other things from about
a zillion small css settings that i am personally not prepared to put in
my time to fix them in dojo. i know that for myself, that i would then
probably live with ugly interface and hate it every time i use it ;)
(jokingly i would compare it to using fvwm on linux)
regards,
david
Re: JCR Explorer
Posted by David Nuescheler <da...@day.com>.
> > ...code speaks louder than
> > words. So I'll continue with my concept based on dojo, if someone beats
> > me to it with ext, then so be it ;-)...
> Whoever does the work gets to decide, so go for it!
absolutely!
regards,
david
--
Visit: http://dev.day.com/ - Day JCR Cup 08 - Win a MacBook Pro
Re: JCR Explorer
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Apr 22, 2008 at 6:03 PM, Craig L. Ching <cc...@mqsoftware.com> wrote:
> ...code speaks louder than
> words. So I'll continue with my concept based on dojo, if someone beats
> me to it with ext, then so be it ;-)...
Whoever does the work gets to decide, so go for it!
-Bertrand, too ignorant about dojo and extjs to have an opinion anyway
Re: JCR Explorer
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Apr 22, 2008 at 6:10 PM, Torgeir Veimo <to...@netenviron.com> wrote:
>
> ...I thought Apache didn't allow GPL'd
> code in their projects. Has that changed with the GPL version 3?...
No, we're not allowed to redistribute GPL code.
-Bertrand
RE: JCR Explorer
Posted by "Craig L. Ching" <cc...@mqsoftware.com>.
> Nevertheless, I agree, that it might be too much to list all
properties
> in the same tree as the nodes. On the other hand, it is sometimes
> usefull. Still I am considering new ways of doing this. In addition, I
> am also considering reworking the whole plugin as since its inception,
I
> have gained many new insights, which should influence a new/better
> implementation. In particular it would be neat to just show the JCR
tree
> but also the Resource tree.
>
> This would also be on my wish-list from the POV of Sling: Not only a
> pure JCR Explorer (which has its own right, absolutely undisputed) but
a
> Resource Explorer, which shows the complete Resource Tree as available
> through the ResourceResolver.
>
Ok, I'll add this to my list of things to think about.
> Regards
> Felix
Cheers,
Craig
RE: JCR Explorer
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Dienstag, den 22.04.2008, 15:55 -0500 schrieb Craig L. Ching:
> 3) Does anyone have any thoughts on how they'd like to see properties
> vs. children (e.g. does everyone agree that the way the Eclipse browser
> works is a good model for this? Or are there certain things that should
> be done differently? I have to admit, I'm not real fond of the Eclipse
> plugin's structure, but maybe I don't completely understand it either).
> I'm sort of of the opinion that properties should not be in the tree,
> the tree should only contain nodes and the properties should be in a
> separate pane when a node is selected in the tree.
I understand, that you don't like how the Eclipse plugin does it. But
the scope is different. You are talking about a JCR Explorer which
controls the complete contents of your window. In this case it totally
makes sense to adhere to the conventions known from the windows
explorer. For the Eclipse plugin, the case is different: I adhere to the
Eclipse Navigator view, which merges folders and files.
Nevertheless, I agree, that it might be too much to list all properties
in the same tree as the nodes. On the other hand, it is sometimes
usefull. Still I am considering new ways of doing this. In addition, I
am also considering reworking the whole plugin as since its inception, I
have gained many new insights, which should influence a new/better
implementation. In particular it would be neat to just show the JCR tree
but also the Resource tree.
This would also be on my wish-list from the POV of Sling: Not only a
pure JCR Explorer (which has its own right, absolutely undisputed) but a
Resource Explorer, which shows the complete Resource Tree as available
through the ResourceResolver.
Regards
Felix
RE: JCR Explorer
Posted by "Craig L. Ching" <cc...@mqsoftware.com>.
Alexander and Bertrand, I just wanted to say thanks to both of you for
answering my questions, gives me a lot to go with ;-)
Cheers,
Craig
Re: JCR Explorer UI considerations
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Apr 23, 2008 at 8:46 PM, Craig L. Ching <cc...@mqsoftware.com> wrote:
> ...I need a system that allows users to create
> pages from a palette of controls that we provide and a way to hook those
> pages and their widgets up to our real-time data. Then I'll need to
> build bridges to other systems (which is outside of the scope of Sling
> of course)....
The topic of pipelines has come up a few times already in Sling
discussions, and I'm convinced that we'll add something to Sling at
some point. So if you have specific needs don't hesitate to expose
them so that we can take them into account. I'm thinking of pipelines
a la Cocoon (though not necessarily based on XML), which can help
build bridges to other systems.
-Bertrand
RE: JCR Explorer UI considerations
Posted by "Craig L. Ching" <cc...@mqsoftware.com>.
> > 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).
>
> Well, this was a general UI idea. I think small icons or simple menus
> are better than a separate tab for operations. Tabs should be used for
> content, not for actions.
>
Maybe, I don't disagree with you, but I'm also concerned with scaling
and not trying to fit too much data on one view. For instance, if you
have 500 properties, you shouldn't feel claustrophobic because there's
too much other stuff on the same pane. Operations could potentially be
handled by context menus on the nodes themselves, however, I'm not sure
I really like context menus.
Let me think about it a bit more and come up with a mock-up and we can
go from there. I still have a lot to figure out and I'm sure my ideas
will change.
> > Yes, agreed. My idea here was to provide something along the lines
> > of a
> > CMS, something I'm ultimately interested in using sling for.
>
> Disclaimer: Sling comes from a CMS company ;-)
>
Yes, I realize that ;-) However, my needs are not for a full-blown,
general-purpose CMS, just a way to do some niche content customization
and templated pages. For instance, I'd looked at Magnolia before and it
was overkill for what we need. I'd actually built something sort of
like Sling last summer (not as robust, of course) on top of Jackrabbit
using renderers decoupled from content (only supporting Velocity), etc.,
very similar idea with URI mapping to a path in the JCR to the content,
just not quite as feature-full as sling or as broad in scope.
Our company provides real-time monitoring and business performance
views, and one of our claims to fame is the ability to customize views
for the users needs (creating "dashboards" if you will). I am now
looking to extend that functionality to the web, where we can
intermingle with other sorts of web technologies, e.g. JSR-168 portals,
non-standard portals (e.g. google, yahoo), BI tools, and other CMS
systems (e.g. BEA ALUI). So I need a system that allows users to create
pages from a palette of controls that we provide and a way to hook those
pages and their widgets up to our real-time data. Then I'll need to
build bridges to other systems (which is outside of the scope of Sling
of course). What we need is a very niche sort of CMS capability for our
base offering and not something I'd expect to find in a general-purpose
CMS. Though it is possible that as users are exposed to this, we might
find a need to build into a CMS that has more of the collaboration you'd
expect from a general-purpose CMS.
Anyway, I digress and I've rambled a bit ;-) Sling seems like a nice
fit for what we need.
> Alex
>
Cheers,
Craig
Re: JCR Explorer UI considerations
Posted by Alexander Klimetschek <ak...@day.com>.
Am 23.04.2008 um 18:16 schrieb Craig L. Ching:
>
> 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).
Well, this was a general UI idea. I think small icons or simple menus
are better than a separate tab for operations. Tabs should be used for
content, not for actions.
> Oh, I'm going to do my damndest to get full keyboard controls ;-)
Yes, that's what I wanted to here ;-)
> Yes, agreed. My idea here was to provide something along the lines
> of a
> CMS, something I'm ultimately interested in using sling for.
Disclaimer: Sling comes from a CMS company ;-)
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
>> Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/ <<
RE: JCR Explorer UI considerations
Posted by "Craig L. Ching" <cc...@mqsoftware.com>.
> 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
Re: JCR Explorer UI considerations
Posted by Alexander Klimetschek <ak...@day.com>.
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
alexander.klimetschek@day.com
>> Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/ <<
JCR Explorer UI considerations
Posted by "Craig L. Ching" <cc...@mqsoftware.com>.
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
Re: JCR Explorer
Posted by Alexander Klimetschek <ak...@day.com>.
Hi Craig!
Am 22.04.2008 um 22:55 schrieb Craig L. Ching:
>
> 2) It appears that the request URI to get the properties of a node is
> [resource URI].json (more or less, there's a depth in there that I
> don't
> quite understand yet).
You can also get the json for an entire subtree of the repository -
simply use an URI of a node that has child nodes, grandchildren and so
on. The depth specifies how many levels of the subtree should be put
into the json. IIRC depth = 0 means current node and its properties
only, 1 would mean to include the child nodes, 2 down to grand
children etc. If you specify "-1", you will get the entire subtree
("infinity").
> Is it safe to assume that users won't have
> content at that URI?
Nodes and properties *are* content! :-)
The important part here is the "json" extension. This triggers the
json export servlet, which is by default active for all content in the
repository. I don't know if it can be overridden, ie. replaced by
another servlet or script that would render the response differently,
but I think this is not a good idea anyway, since it's essentially the
main access for javascript-clients to the repository.
> 3) Does anyone have any thoughts on how they'd like to see properties
> vs. children (e.g. does everyone agree that the way the Eclipse
> browser
> works is a good model for this? Or are there certain things that
> should
> be done differently? I have to admit, I'm not real fond of the
> Eclipse
> plugin's structure, but maybe I don't completely understand it
> either).
> I'm sort of of the opinion that properties should not be in the tree,
> the tree should only contain nodes and the properties should be in a
> separate pane when a node is selected in the tree.
Personally I find the The JCR plugin for Eclipse not perfect regarding
the layout... but this is probably because there are just so many
views in different places each time ;-)
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.
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
>> Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/ <<
Re: JCR Explorer
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Craig,
On Tue, Apr 22, 2008 at 10:55 PM, Craig L. Ching <cc...@mqsoftware.com> wrote:
> ...1) Just about to go digging, but if someone could point me to the code
> that gets the node properties and sends them via json to the browser,
> I'd appreciate it....
The starting point would be the JsonRendererServlet,
https://svn.apache.org/repos/asf/incubator/sling/trunk/sling/servlets-get/src/main/java/org/apache/sling/servlets/JsonRendererServlet.java
> ... 2) It appears that the request URI to get the properties of a node is
> [resource URI].json (more or less, there's a depth in there that I don't
> quite understand yet). Is it safe to assume that users won't have
> content at that URI?...
Not sure what you mean, to get the json values (including properties)
of the node at /foo you'd use /foo.json, or /foo.infinity.json for a
recursive dump. If the node path is /foo.json you'll have to use
/foo.json.json but usually I'd recommend not having extensions in node
paths.
The JsonRenderingTest class has more examples,
https://svn.apache.org/repos/asf/incubator/sling/trunk/launchpad/webapp/src/test/java/org/apache/sling/launchpad/webapp/integrationtest/JsonRenderingTest.java
> ... 3) Does anyone have any thoughts on how they'd like to see properties
> vs. children (e.g. does everyone agree that the way the Eclipse browser
> works is a good model for this? Or are there certain things that should
> be done differently? I have to admit, I'm not real fond of the Eclipse
> plugin's structure, but maybe I don't completely understand it either).
> I'm sort of of the opinion that properties should not be in the tree,
> the tree should only contain nodes and the properties should be in a
> separate pane when a node is selected in the tree....
Agree with that, the left part of the screen could be the node
selector (either a tree or a list of nodes or subtrees in the case of
a search result), and the right part could show the property values,
with (later) custom editors selected according to the property
content.
-Bertrand
RE: JCR Explorer
Posted by "Craig L. Ching" <cc...@mqsoftware.com>.
> that's what david mentioned earlier:
>
> > i think it may well be worth the effort of looking into finding out
what
> we
> > can do around the gplv3 licensing of extjs.
>
Yes, I misunderstood because he said:
" i have recently seen a great example of a very good jcr explorer using
extjs. as a matter of fact i think that this was visually substantially
superior to the dojo/swing based jcr explorers that i have seen in the
past.
i think it may well be worth the effort of looking into finding out what
we can do around the gplv3 licensing of extjs. "
And I took that to mean that he saw a JCR browser that was based on ext
but was GPLv3, not that ext was gplv3 ;-) That was my mistake though.
On that note, I've had a look at the node store and property store and
cleaned up one of the demos there and I have a very basic, but
functioning browser based on that code.
A few questions:
1) Just about to go digging, but if someone could point me to the code
that gets the node properties and sends them via json to the browser,
I'd appreciate it.
2) It appears that the request URI to get the properties of a node is
[resource URI].json (more or less, there's a depth in there that I don't
quite understand yet). Is it safe to assume that users won't have
content at that URI?
3) Does anyone have any thoughts on how they'd like to see properties
vs. children (e.g. does everyone agree that the way the Eclipse browser
works is a good model for this? Or are there certain things that should
be done differently? I have to admit, I'm not real fond of the Eclipse
plugin's structure, but maybe I don't completely understand it either).
I'm sort of of the opinion that properties should not be in the tree,
the tree should only contain nodes and the properties should be in a
separate pane when a node is selected in the tree.
Cheers,
Craig
Re: JCR Explorer
Posted by Tobias Bocanegra <to...@day.com>.
that's what david mentioned earlier:
> i think it may well be worth the effort of looking into finding out what we
> can do around the gplv3 licensing of extjs.
--
toby
On 4/22/08, Craig L. Ching <cc...@mqsoftware.com> wrote:
> > Slightly unrelated, but still relevant; I thought Apache didn't allow
> > GPL'd code in their projects. Has that changed with the GPL version 3?
> >
>
> Good point, I wasn't even aware that ext was GPL, but I just checked and
> so it is. It would probably have to be a separately distributed project
> if that was the way someone went.
>
>
> > --
>
> > Torgeir Veimo
> > torgeir@netenviron.com
> >
> >
> >
>
>
RE: JCR Explorer
Posted by "Craig L. Ching" <cc...@mqsoftware.com>.
> Slightly unrelated, but still relevant; I thought Apache didn't allow
> GPL'd code in their projects. Has that changed with the GPL version 3?
>
Good point, I wasn't even aware that ext was GPL, but I just checked and
so it is. It would probably have to be a separately distributed project
if that was the way someone went.
> --
> Torgeir Veimo
> torgeir@netenviron.com
>
>
>
Re: JCR Explorer
Posted by Torgeir Veimo <to...@netenviron.com>.
On 22 Apr 2008, at 18:03, Craig L. Ching wrote:
> Well, if someone is going to do extjs, that isn't something I'm
> interested in being involved with.
Slightly unrelated, but still relevant; I thought Apache didn't allow
GPL'd code in their projects. Has that changed with the GPL version 3?
--
Torgeir Veimo
torgeir@netenviron.com
RE: JCR Explorer
Posted by "Craig L. Ching" <cc...@mqsoftware.com>.
> hi craig,
> i agree with david that the DOJO ui looks like a child scribbling on
> the screen compared to the sophisticated widgets of extjs. of course
> you're right that UI isn't anything. but also in respect to the js
> library and its usability and extensibility, extjs is great. i would
> really like to have an explorer that has a nice ui and "feels" the
> same as a "normal" filesystem explorer.
>
Well, if someone is going to do extjs, that isn't something I'm
interested in being involved with. So, if that's the requirement, then
I'm not the right person. That said, however, code speaks louder than
words. So I'll continue with my concept based on dojo, if someone beats
me to it with ext, then so be it ;-)
Cheers,
Craig
Re: JCR Explorer
Posted by Tobias Bocanegra <to...@day.com>.
hi craig,
i agree with david that the DOJO ui looks like a child scribbling on
the screen compared to the sophisticated widgets of extjs. of course
you're right that UI isn't anything. but also in respect to the js
library and its usability and extensibility, extjs is great. i would
really like to have an explorer that has a nice ui and "feels" the
same as a "normal" filesystem explorer.
> Personally, I prefer dojo and would rather contribute something based on
> that. If people want to do an ext-based explorer, I'm not sure that's
> something I'd be interested in. As for looks, I'd need you to be more
> specific about how ext is "visually substantially superior." Honestly,
> though, there is more to javascript UI development than just looks ;-)
> I am genuinely interested in your opinion and examples, though, because
> I've seen some really good dojo-based UI's.
do you have examples of such good UIs? because i haven't found any so far :-(
> I do think that the default
> L&F of dojo maybe isn't the best, but I'm certain we wouldn't have to
> live with that.
--
regards, toby
RE: JCR Explorer
Posted by "Craig L. Ching" <cc...@mqsoftware.com>.
> hi craig,
>
Hi David,
> personally, i think that it would be great if the jcr explorer was
backed
> on the
> standard sling json serialization and the standard forms conventions
for
> writing content.
>
I was definitely going to look at the Dojo-based API that is available
in sling already. I like json, so that would be my preference for doing
the browser/server communication anyway and dojo has great support for
that ;-)
> i have recently seen a great example of a very good jcr explorer using
> extjs. as a matter of fact i think that this was visually
> substantially superior to the
> dojo/swing based jcr explorers that i have seen in the past.
> i think it may well be worth the effort of looking into finding out
what
> we
> can do around the gplv3 licensing of extjs.
>
Personally, I prefer dojo and would rather contribute something based on
that. If people want to do an ext-based explorer, I'm not sure that's
something I'd be interested in. As for looks, I'd need you to be more
specific about how ext is "visually substantially superior." Honestly,
though, there is more to javascript UI development than just looks ;-)
I am genuinely interested in your opinion and examples, though, because
I've seen some really good dojo-based UI's. I do think that the default
L&F of dojo maybe isn't the best, but I'm certain we wouldn't have to
live with that.
> just my two cents... ;)
>
> regards,
> david
>
Cheers,
Craig
Re: JCR Explorer
Posted by Peter Svensson <ps...@gmail.com>.
This sounds very good. Perhaps you can find the time to do what I can't :)
Please mail me if you need any assistance or have questions.
Cheers,
PS
On Fri, Apr 25, 2008 at 4:57 PM, Craig L. Ching <cc...@mqsoftware.com>
wrote:
> > And BTW, Lars Trieloff contributed two Dojo data providers for nodes
> and
> > properties, which may be found in the extensions/dojo-sling module.
> > Maybe this can be of any help.
> >
> Already using them ;-) I pulled the SVN repo into a local git repo and
> I'm going to be enhancing both the data store and the servlet that
> provides the JSON properties to add additional information.
>
> > Regards
> > Felix
>
>
RE: JCR Explorer
Posted by "Craig L. Ching" <cc...@mqsoftware.com>.
> And BTW, Lars Trieloff contributed two Dojo data providers for nodes
and
> properties, which may be found in the extensions/dojo-sling module.
> Maybe this can be of any help.
>
Already using them ;-) I pulled the SVN repo into a local git repo and
I'm going to be enhancing both the data store and the servlet that
provides the JSON properties to add additional information.
> Regards
> Felix
Re: JCR Explorer
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Dienstag, den 22.04.2008, 21:50 +0200 schrieb Bertrand Delacretaz:
> On Tue, Apr 22, 2008 at 5:01 PM, David Nuescheler <da...@day.com> wrote:
> > ... personally, i think that it would be great if the jcr explorer was backed on the
> > standard sling json serialization and the standard forms conventions for
> > writing content....
>
> Agreed - and that interface is probably missing some stuff that is
> needed by the explorer (adding mixins to nodes comes to mind, but
> there's probably more), so the explorer will be a good use case to
> find out what those missing pieces are.
And BTW, Lars Trieloff contributed two Dojo data providers for nodes and
properties, which may be found in the extensions/dojo-sling module.
Maybe this can be of any help.
Regards
Felix
Re: JCR Explorer
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Apr 22, 2008 at 5:01 PM, David Nuescheler <da...@day.com> wrote:
> ... personally, i think that it would be great if the jcr explorer was backed on the
> standard sling json serialization and the standard forms conventions for
> writing content....
Agreed - and that interface is probably missing some stuff that is
needed by the explorer (adding mixins to nodes comes to mind, but
there's probably more), so the explorer will be a good use case to
find out what those missing pieces are.
-Bertrand