Re: JCR Explorer (was: Summer of Code is upon us)
Hi Glenn, On Fri, Mar 20, 2009 at 1:05 AM, Glenn Silverman gl...@glenn3.securesites.net wrote: ...Bundlizing a GWT application that runs correctly in Sling needs a workaround to access the generated nocache.js Did you have a look at the Sling code under /contrib/extensions/gwt? I'm not a GWT specialist, but last time at looked that seemed to work. -Bertrand
Re: JCR Explorer (was: Summer of Code is upon us)
Concerning GWT, it seems that we can support HTTP requests [1] (with JSON or XML) and avoid GWT RPC. RPC is certainly nice for java developers but if we want to have a common foundation for the JCR browser that can be integrated with different web UI frameworks, it is certainly better to avoid the RPC model. What do you think about that ? Maybe we can start a prototype based on that. We have an example with Gwt RPC. I will make a test with a full JSON support. [1] http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5s=google-web-toolkit-doc-1-5t=GettingStartedJSON 2009/3/20 Glenn Silverman gl...@glenn3.securesites.net I wish I were at a stage to share some success. Most of you are probably way ahead of me on this. Bundlizing a GWT application that runs correctly in Sling needs a workaround to access the generated nocache.js. Otherwise, connecting externally through an HTTPProxy would work, though not ideal. The gwtext package has a ScriptTagProxy that natively supports JSON and seems like a good candidate. I'm also looking at IBM's JSON4j and AjaxProxy packages. I'm not giving up on GWT as a ui as yet, though. Glenn Silverman... Christophe Lombart wrote: You are welcome to share your experience. We can take the necessary time to choose and compare UI frameworks. Is is possible to see what you are doing with Gwt/Sling ? Thanks 2009/3/19 Glenn Silverman gl...@glenn3.securesites.net I've been getting a lot of mail on this subject, and I'm working on a GWT front end in Sling to create and query repository entries for my own projects. I would certainly be happy to contribute my two-cents to create a full-blown repository explorer. I think there might be an Eclipse incubator project to create one as well, using RCP, or perhaps RAP tooling. Glenn Silverman... Michael Dürig wrote: AFAIR Bertil implemented a simple Sling explorer using MooTools while working on his thesis. See https://issues.apache.org/jira/browse/SLING-840 Michael Bertrand Delacretaz wrote: On Thu, Mar 19, 2009 at 12:37 PM, Christophe Lombart christophe.lomb...@gmail.com wrote: 2009/3/19 Bertrand Delacretaz bdelacre...@apache.org ... Ok - a good JCR explorer is something that many of us are looking forward to, and it's not a trivial task, and Sling's OSGi plugins open some very interesting possibilities I am interested to work on that even if it will take a long time to get a nice result. We can expect that others will be interesting to contribute. Futhermore, it is certainly possible to start with a very simple version and add more and more features. Sure - creating a minimal kernel that allows for editing plugins would be a good start. And the rest (create editing plugins for the Sling JCR Explorer) could still be a GSoC project? Can we based this work on the following proposal [1] ? I think so, and feel free to update that of course. One thing is that the resulting explorer should IMHO be usable for pure JCR repositories (non-Sling), even though the explorer itself would run under Sling. Probably not a big challenge, just one thing to add to the spec. ...What about the UI framework to use ? A JCR Explorer will require advanced UI widgets and I'm wondering which framework will be the more appropriate, Dojo ? Gwt ? Extjs ? ? :-( I have a prototype with Extjs but It is certainly not compatible with the ASF license Yes, that's the problem. We have a few things based on dojo already, and the Felix OSGi console now uses jQuery, so I guess options are open. I think I'd vote for jQuery to have some alignement with the Felix project, but whoever does the job gets to decide I guess. Or better, leave the choice of the UI framework to the set of plugins ;-) -Bertrand [1] http://cwiki.apache.org/SLING/sling-based-jcr-explorer.html
Re: JCR Explorer (was: Summer of Code is upon us)
Concerning GWT, it seems that we can support HTTP requests [1] (with JSON or XML) and avoid GWT RPC. RPC is certainly nice for java developers but if we want to have a common foundation for the JCR browser that can be integrated with different web UI frameworks, it is certainly better to avoid the RPC model. What do you think about that ? I´m absolutely agree with that opinion. In the other hand, my experience with [GWT - JSON - Sling servlets + scripts] has been pretty good. Regards, Juanjo.
Re: JCR Explorer
Hi, Bertrand, Yes, I tried building from /contrib/extensions/gwt, but got the following error: 1 required artifact is missing. for artifact: org.apache.sling:org.apache.sling.extensions.gwt.sample:bundle:2.0.0-incubator -SNAPSHOT from the specified remote repositories: apache.incubating (http://people.apache.org/repo/m2-incubating-repository), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), central (http://repo1.maven.org/maven2) I checked the repos and the required artifact is not in them. Any suggestions, as I would like to see this example working. Glenn Silverman... Bertrand Delacretaz wrote: Hi Glenn, On Fri, Mar 20, 2009 at 1:05 AM, Glenn Silverman gl...@glenn3.securesites.net wrote: ...Bundlizing a GWT application that runs correctly in Sling needs a workaround to access the generated nocache.js Did you have a look at the Sling code under /contrib/extensions/gwt? I'm not a GWT specialist, but last time at looked that seemed to work. -Bertrand
Re: JCR Explorer
Hi, On Fri, Mar 20, 2009 at 5:07 PM, Glenn Silverman gl...@glenn3.securesites.net wrote: Yes, I tried building from /contrib/extensions/gwt, but got the following error: 1 required artifact is missing. for artifact: org.apache.sling:org.apache.sling.extensions.gwt.sample:bundle:2.0.0-incubator -SNAPSHOT Building contrib/extensions/gwt/servlet first, and then /contrib/extensions/gwt/sample, works for me in the current trunk - both with mvn clean install. -Bertrand
Re: JCR Explorer
Bertrand, I finally installed the servlet in my local maven repo and it works. The problem I'm trying to solve is duplicating the create/build process for a simple gwt/sling application. GWT apps are created either with the supplied applicationCreator, or the googlewebtoolkit2 archetype, neither of which generates the directory structure or configuration files needed for packaging as a bundle ala the sling.extensions.gwt.sample projects. And duplicating the rather complex file structure in the sample projects does not lend itself to a test-first scenario for GWT applications. Another concern, is just what specific directory layout/config file combination is really necessary to get gwt working in Sling. Is the layout in the samples the only way? There seems no documentation on this subject. As you can see, I'm full of questions on the subject of Sling and right now, it's a lot of trial-and-error, and that's not very productive. Glenn Silverman... Thanks Bertrand Delacretaz wrote: Hi, On Fri, Mar 20, 2009 at 5:07 PM, Glenn Silverman gl...@glenn3.securesites.net wrote: Yes, I tried building from /contrib/extensions/gwt, but got the following error: 1 required artifact is missing. for artifact: org.apache.sling:org.apache.sling.extensions.gwt.sample:bundle:2.0.0-incubator -SNAPSHOT Building contrib/extensions/gwt/servlet first, and then /contrib/extensions/gwt/sample, works for me in the current trunk - both with mvn clean install. -Bertrand
JCR Explorer (was: Summer of Code is upon us)
On Thu, Mar 19, 2009 at 12:37 PM, Christophe Lombart christophe.lomb...@gmail.com wrote: 2009/3/19 Bertrand Delacretaz bdelacre...@apache.org ... Ok - a good JCR explorer is something that many of us are looking forward to, and it's not a trivial task, and Sling's OSGi plugins open some very interesting possibilities I am interested to work on that even if it will take a long time to get a nice result. We can expect that others will be interesting to contribute. Futhermore, it is certainly possible to start with a very simple version and add more and more features. Sure - creating a minimal kernel that allows for editing plugins would be a good start. And the rest (create editing plugins for the Sling JCR Explorer) could still be a GSoC project? Can we based this work on the following proposal [1] ? I think so, and feel free to update that of course. One thing is that the resulting explorer should IMHO be usable for pure JCR repositories (non-Sling), even though the explorer itself would run under Sling. Probably not a big challenge, just one thing to add to the spec. ...What about the UI framework to use ? A JCR Explorer will require advanced UI widgets and I'm wondering which framework will be the more appropriate, Dojo ? Gwt ? Extjs ? ? :-( I have a prototype with Extjs but It is certainly not compatible with the ASF license Yes, that's the problem. We have a few things based on dojo already, and the Felix OSGi console now uses jQuery, so I guess options are open. I think I'd vote for jQuery to have some alignement with the Felix project, but whoever does the job gets to decide I guess. Or better, leave the choice of the UI framework to the set of plugins ;-) -Bertrand [1] http://cwiki.apache.org/SLING/sling-based-jcr-explorer.html
Re: JCR Explorer (was: Summer of Code is upon us)
2009/3/19 Bertrand Delacretaz bdelacre...@apache.org Sure - creating a minimal kernel that allows for editing plugins would be a good start. Just to avoid confusion ... What do you mean by editing plugins ? a specific editor for each kind of content ? And the rest (create editing plugins for the Sling JCR Explorer) could still be a GSoC project? why not .. Depending on what does mean editing plugins :-). Can we based this work on the following proposal [1] ? I think so, and feel free to update that of course. One thing is that the resulting explorer should IMHO be usable for pure JCR repositories (non-Sling), even though the explorer itself would run under Sling. Probably not a big challenge, just one thing to add to the spec. with use cases like : register a new jcr repo, see the list of available repos, ... ...What about the UI framework to use ? A JCR Explorer will require advanced UI widgets and I'm wondering which framework will be the more appropriate, Dojo ? Gwt ? Extjs ? ? :-( I have a prototype with Extjs but It is certainly not compatible with the ASF license Yes, that's the problem. We have a few things based on dojo already, and the Felix OSGi console now uses jQuery, so I guess options are open. I think I'd vote for jQuery to have some alignement with the Felix project, but whoever does the job gets to decide I guess. Or better, leave the choice of the UI framework to the set of plugins ;-) My personal short list is jquery and gwt but I have to check how gwt can work with Sling. jquery is a little bit young in term of widgets like treeview, grid. I'm just wondering if working with GWT will not be more productive for this kind of application. Christophe -Bertrand [1] http://cwiki.apache.org/SLING/sling-based-jcr-explorer.html
Re: JCR Explorer (was: Summer of Code is upon us)
On Thu, Mar 19, 2009 at 2:24 PM, Christophe Lombart christophe.lomb...@gmail.com wrote: 2009/3/19 Bertrand Delacretaz bdelacre...@apache.org Sure - creating a minimal kernel that allows for editing plugins would be a good start. Just to avoid confusion ... What do you mean by editing plugins ? a specific editor for each kind of content ? Yes, for exemple a rich text editor for a node of type mynodes:text or, nt:unstructured with a mimeType=text/html. ...jquery is a little bit young in term of widgets like treeview, grid. I'm just wondering if working with GWT will not be more productive for this kind of application Why not - I'm not familiar with it (nor with any other UI framework anyway), but the concept looks cool. -Bertrand
Re: JCR Explorer (was: Summer of Code is upon us)
...jquery is a little bit young in term of widgets like treeview, grid. I'm just wondering if working with GWT will not be more productive for this kind of application Why not - I'm not familiar with it (nor with any other UI framework anyway), but the concept looks cool. I'm not familiar with GWT either but if could add my 50 cents I'd propose the use of YUI that is powerful and that has a wide range of widgets. -Bertrand -- Valentin Jacquemin
Re: JCR Explorer (was: Summer of Code is upon us)
AFAIR Bertil implemented a simple Sling explorer using MooTools while working on his thesis. See https://issues.apache.org/jira/browse/SLING-840 Michael Bertrand Delacretaz wrote: On Thu, Mar 19, 2009 at 12:37 PM, Christophe Lombart christophe.lomb...@gmail.com wrote: 2009/3/19 Bertrand Delacretaz bdelacre...@apache.org ... Ok - a good JCR explorer is something that many of us are looking forward to, and it's not a trivial task, and Sling's OSGi plugins open some very interesting possibilities I am interested to work on that even if it will take a long time to get a nice result. We can expect that others will be interesting to contribute. Futhermore, it is certainly possible to start with a very simple version and add more and more features. Sure - creating a minimal kernel that allows for editing plugins would be a good start. And the rest (create editing plugins for the Sling JCR Explorer) could still be a GSoC project? Can we based this work on the following proposal [1] ? I think so, and feel free to update that of course. One thing is that the resulting explorer should IMHO be usable for pure JCR repositories (non-Sling), even though the explorer itself would run under Sling. Probably not a big challenge, just one thing to add to the spec. ...What about the UI framework to use ? A JCR Explorer will require advanced UI widgets and I'm wondering which framework will be the more appropriate, Dojo ? Gwt ? Extjs ? ? :-( I have a prototype with Extjs but It is certainly not compatible with the ASF license Yes, that's the problem. We have a few things based on dojo already, and the Felix OSGi console now uses jQuery, so I guess options are open. I think I'd vote for jQuery to have some alignement with the Felix project, but whoever does the job gets to decide I guess. Or better, leave the choice of the UI framework to the set of plugins ;-) -Bertrand [1] http://cwiki.apache.org/SLING/sling-based-jcr-explorer.html
Re: JCR Explorer (was: Summer of Code is upon us)
I've been getting a lot of mail on this subject, and I'm working on a GWT front end in Sling to create and query repository entries for my own projects. I would certainly be happy to contribute my two-cents to create a full-blown repository explorer. I think there might be an Eclipse incubator project to create one as well, using RCP, or perhaps RAP tooling. Glenn Silverman... Michael Dürig wrote: AFAIR Bertil implemented a simple Sling explorer using MooTools while working on his thesis. See https://issues.apache.org/jira/browse/SLING-840 Michael Bertrand Delacretaz wrote: On Thu, Mar 19, 2009 at 12:37 PM, Christophe Lombart christophe.lomb...@gmail.com wrote: 2009/3/19 Bertrand Delacretaz bdelacre...@apache.org ... Ok - a good JCR explorer is something that many of us are looking forward to, and it's not a trivial task, and Sling's OSGi plugins open some very interesting possibilities I am interested to work on that even if it will take a long time to get a nice result. We can expect that others will be interesting to contribute. Futhermore, it is certainly possible to start with a very simple version and add more and more features. Sure - creating a minimal kernel that allows for editing plugins would be a good start. And the rest (create editing plugins for the Sling JCR Explorer) could still be a GSoC project? Can we based this work on the following proposal [1] ? I think so, and feel free to update that of course. One thing is that the resulting explorer should IMHO be usable for pure JCR repositories (non-Sling), even though the explorer itself would run under Sling. Probably not a big challenge, just one thing to add to the spec. ...What about the UI framework to use ? A JCR Explorer will require advanced UI widgets and I'm wondering which framework will be the more appropriate, Dojo ? Gwt ? Extjs ? ? :-( I have a prototype with Extjs but It is certainly not compatible with the ASF license Yes, that's the problem. We have a few things based on dojo already, and the Felix OSGi console now uses jQuery, so I guess options are open. I think I'd vote for jQuery to have some alignement with the Felix project, but whoever does the job gets to decide I guess. Or better, leave the choice of the UI framework to the set of plugins ;-) -Bertrand [1] http://cwiki.apache.org/SLING/sling-based-jcr-explorer.html
Re: JCR Explorer (was: Summer of Code is upon us)
I will check the code. Thanks 2009/3/19 Michael Dürig michael.due...@day.com AFAIR Bertil implemented a simple Sling explorer using MooTools while working on his thesis. See https://issues.apache.org/jira/browse/SLING-840 Michael Bertrand Delacretaz wrote: On Thu, Mar 19, 2009 at 12:37 PM, Christophe Lombart christophe.lomb...@gmail.com wrote: 2009/3/19 Bertrand Delacretaz bdelacre...@apache.org ... Ok - a good JCR explorer is something that many of us are looking forward to, and it's not a trivial task, and Sling's OSGi plugins open some very interesting possibilities I am interested to work on that even if it will take a long time to get a nice result. We can expect that others will be interesting to contribute. Futhermore, it is certainly possible to start with a very simple version and add more and more features. Sure - creating a minimal kernel that allows for editing plugins would be a good start. And the rest (create editing plugins for the Sling JCR Explorer) could still be a GSoC project? Can we based this work on the following proposal [1] ? I think so, and feel free to update that of course. One thing is that the resulting explorer should IMHO be usable for pure JCR repositories (non-Sling), even though the explorer itself would run under Sling. Probably not a big challenge, just one thing to add to the spec. ...What about the UI framework to use ? A JCR Explorer will require advanced UI widgets and I'm wondering which framework will be the more appropriate, Dojo ? Gwt ? Extjs ? ? :-( I have a prototype with Extjs but It is certainly not compatible with the ASF license Yes, that's the problem. We have a few things based on dojo already, and the Felix OSGi console now uses jQuery, so I guess options are open. I think I'd vote for jQuery to have some alignement with the Felix project, but whoever does the job gets to decide I guess. Or better, leave the choice of the UI framework to the set of plugins ;-) -Bertrand [1] http://cwiki.apache.org/SLING/sling-based-jcr-explorer.html
Re: JCR Explorer (was: Summer of Code is upon us)
You are welcome to share your experience. We can take the necessary time to choose and compare UI frameworks. Is is possible to see what you are doing with Gwt/Sling ? Thanks 2009/3/19 Glenn Silverman gl...@glenn3.securesites.net I've been getting a lot of mail on this subject, and I'm working on a GWT front end in Sling to create and query repository entries for my own projects. I would certainly be happy to contribute my two-cents to create a full-blown repository explorer. I think there might be an Eclipse incubator project to create one as well, using RCP, or perhaps RAP tooling. Glenn Silverman... Michael Dürig wrote: AFAIR Bertil implemented a simple Sling explorer using MooTools while working on his thesis. See https://issues.apache.org/jira/browse/SLING-840 Michael Bertrand Delacretaz wrote: On Thu, Mar 19, 2009 at 12:37 PM, Christophe Lombart christophe.lomb...@gmail.com wrote: 2009/3/19 Bertrand Delacretaz bdelacre...@apache.org ... Ok - a good JCR explorer is something that many of us are looking forward to, and it's not a trivial task, and Sling's OSGi plugins open some very interesting possibilities I am interested to work on that even if it will take a long time to get a nice result. We can expect that others will be interesting to contribute. Futhermore, it is certainly possible to start with a very simple version and add more and more features. Sure - creating a minimal kernel that allows for editing plugins would be a good start. And the rest (create editing plugins for the Sling JCR Explorer) could still be a GSoC project? Can we based this work on the following proposal [1] ? I think so, and feel free to update that of course. One thing is that the resulting explorer should IMHO be usable for pure JCR repositories (non-Sling), even though the explorer itself would run under Sling. Probably not a big challenge, just one thing to add to the spec. ...What about the UI framework to use ? A JCR Explorer will require advanced UI widgets and I'm wondering which framework will be the more appropriate, Dojo ? Gwt ? Extjs ? ? :-( I have a prototype with Extjs but It is certainly not compatible with the ASF license Yes, that's the problem. We have a few things based on dojo already, and the Felix OSGi console now uses jQuery, so I guess options are open. I think I'd vote for jQuery to have some alignement with the Felix project, but whoever does the job gets to decide I guess. Or better, leave the choice of the UI framework to the set of plugins ;-) -Bertrand [1] http://cwiki.apache.org/SLING/sling-based-jcr-explorer.html
JCR Explorer (was: Summer of Code is upon us)
Just FYI there is a *very* basic repository explorer example included as part of the Dojo-Sling bundle, on the demo page /dojox/data/demo/demo4.html. It refers to some sample content that appears to have disappeared from the build (at /samplenodes), so it doesn't work out of the box. If you search replace in that file changing: url=/samplenodes to url=/, that should fix it (though it will also make some of the ComboBox examples incredibly slow depending on the size of your repo). Once fixed, if you click on the Complete tab, you get a left-pane tree view of the repo, and a right-pane details view of the selected node's properties. You can also add properties to the selected node. It currently makes no attempt to distinguish between different node types, provide specialized editors for different property types, handle binary content etc. You also can't add new nodes :-) Also due to the current way the SlingNodeStore SlingPropertyStore are implemented, changes are persisted immediately. I'm working on a fix that will allow an edit/commit style interaction with those stores. If you're having trouble getting it working, make sure to upgrade your Dojo bundle to the latest 1.2.x release (1.2.3 I believe). Bertrand Delacretaz wrote: Sure - creating a minimal kernel that allows for editing plugins would be a good start. And the rest (create editing plugins for the Sling JCR Explorer) could still be a GSoC project?
RE: JCR Explorer (was: Summer of Code is upon us)
Hi - In working on a CMS project, using a jackrabbit/jcr based product, we wanted similar functionality - a way to browse the repo. We found a google code project called jc-rest: http://code.google.com/p/jc-rest/ It has this type of functionality, and is based on YUI. It works well for getting an easy view into all details of the repository. Currently, it only exposes a single workspace, but I don't think it would be hard to change that to expose all workspaces. As for running it as a bundle in sling, you may be able to refactor the YUI/JavaScript code in the browser to use sling urls, instead of the RESTful services that jc-rest provides on server side. I have also considered creating a Flex/Flash version of something like this. Tyson -Original Message- From: Valentin Jacquemin [mailto:jacquem...@gmail.com] Sent: Thursday, March 19, 2009 7:07 AM To: sling-dev@incubator.apache.org Subject: Re: JCR Explorer (was: Summer of Code is upon us) ...jquery is a little bit young in term of widgets like treeview, grid. I'm just wondering if working with GWT will not be more productive for this kind of application Why not - I'm not familiar with it (nor with any other UI framework anyway), but the concept looks cool. I'm not familiar with GWT either but if could add my 50 cents I'd propose the use of YUI that is powerful and that has a wide range of widgets. -Bertrand -- Valentin Jacquemin This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. Dissemination, distribution or copying of this email or the information herein by anyone other than the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, is prohibited. If you have received this email in error, please immediately notify us by calling our Help Desk at (415) 581-5552 or by e-mailing us at helpd...@organic.com.
Re: JCR Explorer (was: Summer of Code is upon us)
On 19 Mar 2009, at 17:09, Tyson Norris wrote:
Hi -
In working on a CMS project, using a jackrabbit/jcr based product, we
wanted similar functionality - a way to browse the repo.
We found a google code project called jc-rest:
http://code.google.com/p/jc-rest/
It has this type of functionality, and is based on YUI. It works well
for getting an easy view into all details of the repository.
Currently,
it only exposes a single workspace, but I don't think it would be hard
to change that to expose all workspaces.
As for running it as a bundle in sling, you may be able to refactor
the
YUI/JavaScript code in the browser to use sling urls, instead of the
RESTful services that jc-rest provides on server side.
Here's a very simple adaptation of the jc-rest browser to use sling
JSON requests (run it in firefox).
There's a limit to what you can do without any server side component
though, and I think that determining which capabilities to incorporate
into that component is much more interesting than the client side
javascript implementation. The latter could probably be left as an
exercise to the reader, as it's mostly about the JS framework, not
sling per se. A nice, compact default one wouldn't hurt though.
!DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd
html
head
meta http-equiv=Content-Type content=text/html;
charset=UTF-8
meta http-equiv=Cache-Control content=No-Cache
titleRepository Browser/title
!-- Combo-handled YUI CSS files: --
link rel=stylesheet type=text/css href=http://yui.yahooapis.com/combo?2.6.0/build/assets/skins/sam/skin.css
!-- Additional custom style rules from yahoo treeview example
--
link rel=stylesheet type=text/css href=http://developer.yahoo.com/yui/examples/treeview/assets/css/folders/tree.css
style type=text/css
.icon-leaf { display:block; height: 22px; padding-left: 20px;
background: transparent url(http://developer.yahoo.com/yui/examples/treeview/assets/img/icons.png
) 0 -108px no-repeat; }
* { font: 10pt verdana, sans-serif; }
/style
!-- Combo-handled YUI JS files: --
script type=text/javascript src=http://yui.yahooapis.com/combo?2.6.0/build/yahoo-dom-event/yahoo-dom-event.js2.6.0/build/connection/connection-min.js2.6.0/build/datasource/datasource-min.js2.6.0/build/dragdrop/dragdrop-min.js2.6.0/build/element/element-beta-min.js2.6.0/build/datatable/datatable-min.js2.6.0/build/resize/resize-min.js2.6.0/build/layout/layout-min.js2.6.0/build/treeview/treeview-min.js
/script
/head
body class=yui-skin-sam
div id=tree/div
div id=detail/div
div id=blank/div
script
(function() {
var Dom = YAHOO.util.Dom, Event =
YAHOO.util.Event;
Event.onDOMReady(function() {
var layout = new YAHOO.widget.Layout({
units: [
{position: 'left', body: 'tree', width: 512, gutter: '5px',
resize: true, scroll: true},
{position: 'center', body: 'detail', gutter: '5px', resize:
true, scroll: true},
{position: 'right',
body: 'blank', width: 0, gutter: '5px'}
]
});
layout.render();
});
})();
/script
script type=text/javascript
var myDataSource;
var myDataTable;
YAHOO.example.treeExample = function() {
var tree;
function loadNodeData(node, fnLoadComplete) {
// construct node path
var path = /;
if (node.depth 0) {
for (var i = 1, j = node.depth; i
j; i++) {
path = path +
node.getAncestor(i).label + /;
}
path = path + node.label;
}
// append .1.json to fetch immediate
children with their properties
var sUrl = + path + .1.json;
var callback = {
success:
Re: JCR Explorer (was: Summer of Code is upon us)
On Thu, Mar 19, 2009 at 5:38 PM, Torgeir Veimo torg...@pobox.com wrote: ...There's a limit to what you can do without any server side component though, and I think that determining which capabilities to incorporate into that component is much more interesting than the client side javascript implementation. The latter could probably be left as an exercise to the reader, as it's mostly about the JS framework, not sling per se Very good point - identifying and implementing what's missing (if anything) from Sling's current RESTful interface to create an efficient client-side browser is probably the best way to tackle this. And the browser then becomes an excellent example of how to use that RESTful interface. -Bertrand (pleased to see so many people and good stuff in this thread ;-)
Re: JCR Explorer (was: Summer of Code is upon us)
Just to add my 2 cents: as we're talking about sling here, the explorer should rather be based on the resource tree and not be tied directly to jcr. If someone wants to develop a pure jcr explorer based on Sling, that's of course fine as well, but the real thing would be resource based :) Carsten -- Carsten Ziegeler cziege...@apache.org
Re: JCR Explorer (was: Summer of Code is upon us)
On Thu, Mar 19, 2009 at 6:19 PM, Carsten Ziegeler cziege...@apache.org wrote: Just to add my 2 cents: as we're talking about sling here, the explorer should rather be based on the resource tree and not be tied directly to jcr Agreed, and that wouldn't prevent connecting it to any compliant JCR repository anyway, right? -Bertrand
Re: JCR Explorer (was: Summer of Code is upon us)
Bertrand Delacretaz wrote: On Thu, Mar 19, 2009 at 6:19 PM, Carsten Ziegeler cziege...@apache.org wrote: Just to add my 2 cents: as we're talking about sling here, the explorer should rather be based on the resource tree and not be tied directly to jcr Agreed, and that wouldn't prevent connecting it to any compliant JCR repository anyway, right? Exactly, that's still possible. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: JCR Explorer (was: Summer of Code is upon us)
...What about the UI framework to use ? A JCR Explorer will require advanced UI widgets and I'm wondering which framework will be the more appropriate, Dojo ? Gwt ? Extjs ? ? :-( I have a prototype with Extjs but It is certainly not compatible with the ASF license At this point my preference would be GWT. I think cross-browser compatibility is very important no matter wich UI framework we choose. Regarding this, my personal experience with ExtJS has not been successful. Anyway, IMHO we should care that the user interactions remain as simple as possible and pay attention to usability concerns. With frameworks such as ExtJS it´s easy to make things more complicated that they really are. For instance, have a look at 37signals applications [1]. I love their simplicity and usability. Take this just as an example of what i mean. BR, Juanjo. [1] http://www.37signals.com/
Re: JCR Explorer (was: Summer of Code is upon us)
Did we really rule out JQuery completely? The most recent versions have really been very nice.. Paul
Re: JCR Explorer (was: Summer of Code is upon us)
I wish I were at a stage to share some success. Most of you are probably way ahead of me on this. Bundlizing a GWT application that runs correctly in Sling needs a workaround to access the generated nocache.js. Otherwise, connecting externally through an HTTPProxy would work, though not ideal. The gwtext package has a ScriptTagProxy that natively supports JSON and seems like a good candidate. I'm also looking at IBM's JSON4j and AjaxProxy packages. I'm not giving up on GWT as a ui as yet, though. Glenn Silverman... Christophe Lombart wrote: You are welcome to share your experience. We can take the necessary time to choose and compare UI frameworks. Is is possible to see what you are doing with Gwt/Sling ? Thanks 2009/3/19 Glenn Silverman gl...@glenn3.securesites.net I've been getting a lot of mail on this subject, and I'm working on a GWT front end in Sling to create and query repository entries for my own projects. I would certainly be happy to contribute my two-cents to create a full-blown repository explorer. I think there might be an Eclipse incubator project to create one as well, using RCP, or perhaps RAP tooling. Glenn Silverman... Michael Dürig wrote: AFAIR Bertil implemented a simple Sling explorer using MooTools while working on his thesis. See https://issues.apache.org/jira/browse/SLING-840 Michael Bertrand Delacretaz wrote: On Thu, Mar 19, 2009 at 12:37 PM, Christophe Lombart christophe.lomb...@gmail.com wrote: 2009/3/19 Bertrand Delacretaz bdelacre...@apache.org ... Ok - a good JCR explorer is something that many of us are looking forward to, and it's not a trivial task, and Sling's OSGi plugins open some very interesting possibilities I am interested to work on that even if it will take a long time to get a nice result. We can expect that others will be interesting to contribute. Futhermore, it is certainly possible to start with a very simple version and add more and more features. Sure - creating a minimal kernel that allows for editing plugins would be a good start. And the rest (create editing plugins for the Sling JCR Explorer) could still be a GSoC project? Can we based this work on the following proposal [1] ? I think so, and feel free to update that of course. One thing is that the resulting explorer should IMHO be usable for pure JCR repositories (non-Sling), even though the explorer itself would run under Sling. Probably not a big challenge, just one thing to add to the spec. ...What about the UI framework to use ? A JCR Explorer will require advanced UI widgets and I'm wondering which framework will be the more appropriate, Dojo ? Gwt ? Extjs ? ? :-( I have a prototype with Extjs but It is certainly not compatible with the ASF license Yes, that's the problem. We have a few things based on dojo already, and the Felix OSGi console now uses jQuery, so I guess options are open. I think I'd vote for jQuery to have some alignement with the Felix project, but whoever does the job gets to decide I guess. Or better, leave the choice of the UI framework to the set of plugins ;-) -Bertrand [1] http://cwiki.apache.org/SLING/sling-based-jcr-explorer.html
[jira] Commented: (SLING-513) How to run the JCR Explorer with Sling?
[ https://issues.apache.org/jira/browse/SLING-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12661147#action_12661147 ] Bertrand Delacretaz commented on SLING-513: --- I have written a blog post at http://grep.codeconsult.ch/2009/01/06/using-the-jcr-explorer-with-sling/ - we might want to transfer that to our website at some point, but it's specific to Tomcat. How to run the JCR Explorer with Sling? --- Key: SLING-513 URL: https://issues.apache.org/jira/browse/SLING-513 Project: Sling Issue Type: Improvement Components: Documentation Reporter: Bertrand Delacretaz Priority: Minor It would be good to have a How-To document about using the JCR Explorer (http://www.jcr-explorer.org/, or another one?) with the Sling Launchpad. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (SLING-513) How to run the JCR Explorer with Sling?
Hi, Am Samstag, den 14.06.2008, 00:16 +0200 schrieb Jean-Yves Cronier: There is also another JCR Browser : http://sourceforge.net/projects/jcrbrowser Is it possible with this Eclipse plugin? Yes. It should be possible to connect to the repository embedded in Sling using RMI. by default the Sling embedded Jackrabbit repository is exposed in an RMI registry at port 1099 (the default RMI port) under the name jackrabbit. Hope this helps. Regards Felix
[jira] Created: (SLING-518) JCR-Explorer -- Add support for a meta selector to support richer information about node properties
JCR-Explorer -- Add support for a meta selector to support richer information about node properties - Key: SLING-518 URL: https://issues.apache.org/jira/browse/SLING-518 Project: Sling Issue Type: New Feature Components: Commons JSON, Servlets Get Reporter: Craig L. Ching Priority: Minor This is the first patch for the JCR Explorer functionality, I'll continue to prepend JCR-Explorer to related JIRA issues. This implements a new JSON rendering needed by the JCR Explorer. I'd originally asked to enhance the existing JSON interfaces to the repository to provide the JCR node properties as JSON objects rather than simple key/value pairs, but Alex suggested [1] that that would break existing operations and that I should create a new metadata selector to key the different rendering. That said, I'm not entirely thrilled about this patch. It certainly works and was easy enough to create, however, it is mostly just a copy of the existing JsonItemWriter and maintaining two objects that are so similar is surely less than ideal. But I didn't see an easy way to enhance the existing JsonItemWriter without fundamentally changing it. So I'm just throwing this over the wall to get some feedback/suggestions on how best to proceed. I haven't implemented any tests for this, I'll see what I can whip up. Hopefully there are already test cases for JsonItemWriter and JsonRendererServlet that I can base some tests on. Ideally, I'd like to get this functionality sorted out and committed before I submit the rest of the JCR Explorer implementation as the rest is non-intrusive and dependent on this. [1] -- http://mail-archives.apache.org/mod_mbox/incubator-sling-dev/200805.mbox/[EMAIL PROTECTED] NOTE: I'll attach a patch in the next comment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SLING-518) JCR-Explorer -- Add support for a meta selector to support richer information about node properties
[ https://issues.apache.org/jira/browse/SLING-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12603170#action_12603170 ] craigching edited comment on SLING-518 at 6/6/08 1:48 PM: -- Patch for functionality as described in the Description. was (Author: craigching): Patch for functionality described in comment 1. JCR-Explorer -- Add support for a meta selector to support richer information about node properties - Key: SLING-518 URL: https://issues.apache.org/jira/browse/SLING-518 Project: Sling Issue Type: New Feature Components: Commons JSON, Servlets Get Reporter: Craig L. Ching Priority: Minor Attachments: SLING-518-001.patch This is the first patch for the JCR Explorer functionality, I'll continue to prepend JCR-Explorer to related JIRA issues. This implements a new JSON rendering needed by the JCR Explorer. I'd originally asked to enhance the existing JSON interfaces to the repository to provide the JCR node properties as JSON objects rather than simple key/value pairs, but Alex suggested [1] that that would break existing operations and that I should create a new metadata selector to key the different rendering. That said, I'm not entirely thrilled about this patch. It certainly works and was easy enough to create, however, it is mostly just a copy of the existing JsonItemWriter and maintaining two objects that are so similar is surely less than ideal. But I didn't see an easy way to enhance the existing JsonItemWriter without fundamentally changing it. So I'm just throwing this over the wall to get some feedback/suggestions on how best to proceed. I haven't implemented any tests for this, I'll see what I can whip up. Hopefully there are already test cases for JsonItemWriter and JsonRendererServlet that I can base some tests on. Ideally, I'd like to get this functionality sorted out and committed before I submit the rest of the JCR Explorer implementation as the rest is non-intrusive and dependent on this. [1] -- http://mail-archives.apache.org/mod_mbox/incubator-sling-dev/200805.mbox/[EMAIL PROTECTED] NOTE: I'll attach a patch in the next comment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-518) JCR-Explorer -- Add support for a meta selector to support richer information about node properties
[ https://issues.apache.org/jira/browse/SLING-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L. Ching updated SLING-518: - Attachment: SLING-518-001.patch Patch for functionality described in comment 1. JCR-Explorer -- Add support for a meta selector to support richer information about node properties - Key: SLING-518 URL: https://issues.apache.org/jira/browse/SLING-518 Project: Sling Issue Type: New Feature Components: Commons JSON, Servlets Get Reporter: Craig L. Ching Priority: Minor Attachments: SLING-518-001.patch This is the first patch for the JCR Explorer functionality, I'll continue to prepend JCR-Explorer to related JIRA issues. This implements a new JSON rendering needed by the JCR Explorer. I'd originally asked to enhance the existing JSON interfaces to the repository to provide the JCR node properties as JSON objects rather than simple key/value pairs, but Alex suggested [1] that that would break existing operations and that I should create a new metadata selector to key the different rendering. That said, I'm not entirely thrilled about this patch. It certainly works and was easy enough to create, however, it is mostly just a copy of the existing JsonItemWriter and maintaining two objects that are so similar is surely less than ideal. But I didn't see an easy way to enhance the existing JsonItemWriter without fundamentally changing it. So I'm just throwing this over the wall to get some feedback/suggestions on how best to proceed. I haven't implemented any tests for this, I'll see what I can whip up. Hopefully there are already test cases for JsonItemWriter and JsonRendererServlet that I can base some tests on. Ideally, I'd like to get this functionality sorted out and committed before I submit the rest of the JCR Explorer implementation as the rest is non-intrusive and dependent on this. [1] -- http://mail-archives.apache.org/mod_mbox/incubator-sling-dev/200805.mbox/[EMAIL PROTECTED] NOTE: I'll attach a patch in the next comment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-513) How to run the JCR Explorer with Sling?
How to run the JCR Explorer with Sling? --- Key: SLING-513 URL: https://issues.apache.org/jira/browse/SLING-513 Project: Sling Issue Type: Improvement Components: Documentation Reporter: Bertrand Delacretaz Priority: Minor It would be good to have a How-To document about using the JCR Explorer (http://www.jcr-explorer.org/, or another one?) with the Sling Launchpad. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JCR Explorer
Hi, Am Dienstag, den 22.04.2008, 21:50 +0200 schrieb Bertrand Delacretaz: On Tue, Apr 22, 2008 at 5:01 PM, David Nuescheler [EMAIL PROTECTED] 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
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
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 [EMAIL PROTECTED] 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
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
...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
JCR Explorer UI considerations
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 UI considerations
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/
RE: JCR Explorer UI considerations
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
Re: JCR Explorer UI considerations
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 [EMAIL PROTECTED] Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/
RE: JCR Explorer UI considerations
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
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
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 LF 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 requirements (was: Welcome Janandith...)
I have started a wiki page at http://cwiki.apache.org/confluence/display/SLING/Sling-based+JCR+explore r with (very rough for now) requirements, feel free to refine as needed. Excellent, I'll start gathering thoughts and try to add to that. Note that there are some experiments using Dojo as the client-side library (hmm...IIRC we need to answer Peter about that), using Dojo might make it easier to get synergies. Yep, that's my intent, I'm going to go slogging through the code today a bit ... -Bertrand
Re: JCR Explorer
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 LF of dojo maybe isn't the best, but I'm certain we wouldn't have to live with that. -- regards, toby
Re: JCR 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 ;-) 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 LF 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
On Tue, Apr 22, 2008 at 6:03 PM, Craig L. Ching [EMAIL PROTECTED] 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
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 LF 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 LF 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
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 [EMAIL PROTECTED]
Re: JCR Explorer
On Tue, Apr 22, 2008 at 6:10 PM, Torgeir Veimo [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED]
Re: JCR Explorer
On Tue, Apr 22, 2008 at 5:01 PM, David Nuescheler [EMAIL PROTECTED] 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
Re: JCR Explorer
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
RE: JCR Explorer
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
Hi Craig, On Tue, Apr 22, 2008 at 10:55 PM, Craig L. Ching [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/
RE: JCR Explorer
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 (was: Re: Clearing JCR repository)
hi craig, there is currently a GSoC project addressing the JCR Explorer/Browser [0]. It is not clear yet if this project gets accepted. the final decisions are made by the end of this week (IIRC). if the project is declined i think it would make sense to follow up on this. i'm happy to give directions if needed. AFAIK the dojo libraries are already available as OSGI bundle and included in sling. so let's wait the results of the GSoC project. Sure, sounds good.
