You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2009/03/19 13:43:03 UTC
JCR Explorer (was: Summer of Code is upon us)
On Thu, Mar 19, 2009 at 12:37 PM, Christophe Lombart
<ch...@gmail.com> wrote:
> 2009/3/19 Bertrand Delacretaz <bd...@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)
Posted by Paul Noden <no...@nodster.co.uk>.
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)
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
>> ...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/
JCR Explorer (was: Summer of Code is upon us)
Posted by Rory Douglas <ro...@oracle.com>.
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)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Mar 19, 2009 at 5:38 PM, Torgeir Veimo <to...@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)
Posted by Torgeir Veimo <to...@pobox.com>.
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">
<title>Repository 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.js&2.6.0/build/connection/connection-min.js&2.6.0/build/datasource/datasource-min.js&2.6.0/build/dragdrop/dragdrop-min.js&2.6.0/build/element/element-beta-min.js&2.6.0/build/datatable/datatable-min.js&2.6.0/build/resize/resize-min.js&2.6.0/build/layout/layout-min.js&2.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: function(oResponse) {
YAHOO.log("XHR transaction was successful.", "info", "example");
var oResults = eval("(" + oResponse.responseText + ")");
if ((oResults)) {
if (YAHOO.lang.isObject(oResults)) {
for (i in oResults) {
if (YAHOO.lang.isObject(oResults[i])) {
var tempNode = new YAHOO.widget.TextNode(i, node, false);
// should probably determine isLeaf based on wether node
can have children
if (oResults[i]["jcr:primaryType"] != 'sling:Folder' &&
oResults[i]["jcr:primaryType"] != 'nt:folder' &&
oResults[i]["jcr:primaryType"] != 'nt:unstructured' &&
(oResults[i]["jcr:primaryType"] && oResults[i]
["jcr:primaryType"].substr(0,4) != 'rep:')) {
tempNode.isLeaf = true;
tempNode.labelStyle = "icon-leaf";
}
}
}
} else {
alert(YAHOO.lang.dump(oResults));
var tempNode = new YAHOO.widget.TextNode(oResults.@name,
node, false);
}
}
oResponse.argument.fnLoadComplete();
},
failure: function(oResponse) {
YAHOO.log("Failed to process XHR transaction.", "info",
"example");
oResponse.argument.fnLoadComplete();
},
argument: {
"node": node,
"fnLoadComplete": fnLoadComplete
},
timeout: 7000
};
YAHOO.util.Connect.asyncRequest('GET', sUrl, callback);
}
function buildTree() {
tree = new YAHOO.widget.TreeView("tree");
tree.setDynamicLoad(loadNodeData, "mode0");
var root = tree.getRoot();
var tempNode = new YAHOO.widget.TextNode("/", root, false);
// add node click callback to show node properties in right hand
pane
tree.subscribe("labelClick", function(node) {
var myCallback = function() {
this.set("sortedBy", null);
this.onDataReturnReplaceRows.apply(this, arguments);
};
var callback1 = {
success : myCallback,
failure : myCallback,
scope : myDataTable
};
// construct path for node
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 .json to fetch node properties in json format
myDataSource.sendRequest(path + ".json", callback1);
});
tree.draw();
}
return {
init: function() {
buildTree();
}
}
} ();
YAHOO.util.Event.onDOMReady(YAHOO.example.treeExample.init,
YAHOO.example.treeExample,true);
YAHOO.util.Event.addListener(window, "load", function() {
YAHOO.example.XHR_JSON = function() {
var myColumnDefs = [
{key:"name", sortable:true, resizeable:true},
{key:"value", sortable:true, resizeable:true}
];
myDataSource = new YAHOO.util.DataSource("");
myDataSource.responseType = YAHOO.util.DataSource.TYPE_JSON;
myDataSource.connXhrMode = "queueRequests";
myDataSource.responseSchema = {
resultsList: "properties",
fields: [ "name", "value" ]
};
myDataTable = new YAHOO.widget.DataTable("detail", myColumnDefs,
myDataSource, {scrollable:true, initialRequest:".json"});
// custom handling of data, since json returned contains object
properties, not array items
myDataSource.doBeforeParseData = function (oRequest,
oFullResponse) {
var oNewResponse = "";
for (var j in oFullResponse) {
oNewResponse = oNewResponse + '{"name":"'+j
+'","value":"'+oFullResponse[j]+'"},\n';
}
oNewResponse = '({"properties":[' + oNewResponse
+ ']})';
return eval(oNewResponse);
};
var mySuccessHandler = function(request, response, payload) {
for (var rate in response) {
alert(YAHOO.lang.dump(rate));
}
this.set("sortedBy", null);
this.onDataReturnAppendRows.apply(this, arguments);
};
var myFailureHandler = function() {
this.showTableMessage(YAHOO.widget.DataTable.MSG_ERROR,
YAHOO.widget.DataTable.CLASS_ERROR);
this.onDataReturnAppendRows.apply(this, arguments);
};
var callbackObj = {
success : mySuccessHandler,
failure : myFailureHandler,
scope : myDataTable
};
return {
oDS: myDataSource,
oDT: myDataTable
};
}();
});
</script>
</body>
</html>
--
Torgeir Veimo
torgeir@pobox.com
RE: JCR Explorer (was: Summer of Code is upon us)
Posted by Tyson Norris <tn...@organic.com>.
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:jacqueminv@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 helpdesk@organic.com.
Re: JCR Explorer (was: Summer of Code is upon us)
Posted by Valentin Jacquemin <ja...@gmail.com>.
>
> > ...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)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Mar 19, 2009 at 2:24 PM, Christophe Lombart
<ch...@gmail.com> wrote:
> 2009/3/19 Bertrand Delacretaz <bd...@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)
Posted by Christophe Lombart <ch...@gmail.com>.
2009/3/19 Bertrand Delacretaz <bd...@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)
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
> 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 (was: Summer of Code is upon us)
Posted by Christophe Lombart <ch...@gmail.com>.
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-5&s=google-web-toolkit-doc-1-5&t=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
>>>>> <ch...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> 2009/3/19 Bertrand Delacretaz <bd...@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
Posted by Glenn Silverman <gl...@glenn3.securesites.net>.
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
>
>
Re: JCR Explorer
Posted by Bertrand Delacretaz <bd...@apache.org>.
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
Posted by Glenn Silverman <gl...@glenn3.securesites.net>.
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 (was: Summer of Code is upon us)
Posted by Bertrand Delacretaz <bd...@apache.org>.
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)
Posted by 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
>>>> <ch...@gmail.com> wrote:
>>>>
>>>>
>>>>> 2009/3/19 Bertrand Delacretaz <bd...@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)
Posted by Christophe Lombart <ch...@gmail.com>.
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
>>> <ch...@gmail.com> wrote:
>>>
>>>> 2009/3/19 Bertrand Delacretaz <bd...@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)
Posted by 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
>> <ch...@gmail.com> wrote:
>>> 2009/3/19 Bertrand Delacretaz <bd...@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)
Posted by Christophe Lombart <ch...@gmail.com>.
I will check the code. Thanks
2009/3/19 Michael Dürig <mi...@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
>> <ch...@gmail.com> wrote:
>>
>>> 2009/3/19 Bertrand Delacretaz <bd...@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)
Posted by Michael Dürig <mi...@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
> <ch...@gmail.com> wrote:
>> 2009/3/19 Bertrand Delacretaz <bd...@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)
Posted by Carsten Ziegeler <cz...@apache.org>.
Bertrand Delacretaz wrote:
> On Thu, Mar 19, 2009 at 6:19 PM, Carsten Ziegeler <cz...@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
cziegeler@apache.org
Re: JCR Explorer (was: Summer of Code is upon us)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Mar 19, 2009 at 6:19 PM, Carsten Ziegeler <cz...@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)
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org