You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Peter Chiochetti <pc...@myzel.net> on 2009/07/17 18:52:53 UTC
Re: Versioning using the SlingPostServlet
On Tue, May 19, 2009 at 09:44:39PM +0100, Ian Boston wrote:
> AFACT, Sling by default does not perform check in's except in the
> content loader.
Its easy to add the versionable mixin with a POST:
$ curl -F"jcr:mixinTypes=mix:versionable" http://....
and jackrabbit JCR seems to honor that (a node dump shows
some new properties). Yet, or as expected, another post to
same node does not create a revision in the JCR.
- Do I have to create my own POST script for that purpose,
which does the checkout/in?
- If so, can I avoid replicating all of the used functionality
of slingPostServlet?
Is there a way to wrap it in ESP, so that it only has to
"checkout(); processPostInServlet(); checkin()" or such?
Thank You.
--
peter
Re: Versioning using the SlingPostServlet
Posted by Peter Chiochetti <pc...@myzel.net>.
On Mon, Jul 20, 2009 at 05:35:46PM +0200, Alexander Klimetschek wrote:
>
> Of course, just use the JCR API in the esp. The post you mention
> already does it.
Indeed, I did not notice (I am in for the fun :). In fact,
# currentNode.checkin(); currentNode.checkout();
in an ESP does it all.
Thank You.
--
peter
Re: Versioning using the SlingPostServlet
Posted by Alexander Klimetschek <ak...@day.com>.
On Mon, Jul 20, 2009 at 12:51 PM, Peter Chiochetti<pc...@myzel.net> wrote:
> There is a way to get the versions with ESP, see Bertrand Delacretaz' post
> here - http://markmail.org/message/dvr7kgvz5qhiqprm
>
> Is there also a way to create a revision with ESP, to call the jcr-api and
> do the checkin/checkout? (I'd rather get by without writing a servlet.)
Of course, just use the JCR API in the esp. The post you mention
already does it.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: GroupId and ArtifactId for Opencloud
Posted by Carsten Ziegeler <cz...@apache.org>.
Amitava Chakraborty wrote:
> Hi,
>
> I am trying to implement tag cloud in an application based on Sling 3. I am
> using the following API for implementing tagcloud -
> " it.exprivia.cnos.opencloud.* " The bundle generated from the opencloud jar
> is opencloud 1.0. I am not getting the proper GroupId and ArtifactId for
> this bundle. Any suggestion/advice would be of great help.
>
I assume you're using maven (at least group id and artifact id suggest
this), so usually you just set them in your pom.xml for your project.
If you're using maven, then this question might be more suited for the
maven user list.
If you're using any other tool, then you might want to ask this question
in the user list for that tool.
HTH
Carsten
> Thanks in advance,
> Amitava
>
>
--
Carsten Ziegeler
cziegeler@apache.org
GroupId and ArtifactId for Opencloud
Posted by Amitava Chakraborty <am...@eforceglobal.com>.
Hi,
I am trying to implement tag cloud in an application based on Sling 3. I am
using the following API for implementing tagcloud -
" it.exprivia.cnos.opencloud.* " The bundle generated from the opencloud jar
is opencloud 1.0. I am not getting the proper GroupId and ArtifactId for
this bundle. Any suggestion/advice would be of great help.
Thanks in advance,
Amitava
Re: Versioning using the SlingPostServlet
Posted by Peter Chiochetti <pc...@myzel.net>.
Thank you all,
There is a way to get the versions with ESP, see Bertrand Delacretaz'
post here - http://markmail.org/message/dvr7kgvz5qhiqprm
Is there also a way to create a revision with ESP, to call the jcr-api
and do the checkin/checkout? (I'd rather get by without writing a servlet.)
PS: Actually, I wanted to use the version store for something similar to
audit, just like eg. the metawiki changes history. Therefore creating a
revision should not depend on client actions, but unconditionally be up
to the server.
I suspect, a ":redirect" from a POST makes the client do a GET, so this
will not be enough to create a revision semiautomatically (except in
case of network failure or tinkering...), or not in a truly RESTful way...
--
peter
Re: Versioning using the SlingPostServlet
Posted by Ian Boston <ie...@tfd.co.uk>.
In our case, we looked at something close to this and decided not to
do that for 2 reasons:
1. We wanted the save operation to appear in the http logs for audit
purposes.
2. The UI developers, who are the users in our case voted that *.save
was clearer than semantics within the POST parameters, and bound the
operation to Resource in general rather than directly to JCR.
However, making it a POST parameter *and* throughly documenting it
(and all other operations) might address their concerns.
-------------
That was our users, jcr:isCheckedOut *might* be perfect for the wider
sling community.
Ian
(The UI developers still have a requirement to get a list of versions
and the retrieve a version)
On 19 Jul 2009, at 22:47, Tobias Bocanegra wrote:
> hi,
> i think the sling post servlet should leverage the content storage
> metaphor as much as possible, i.e. controlling the versioning
> operations with normal properties. eg: providing a
> "jcr:isCheckedOut=true" ensures that the node is checked out,
> providing a "jcr:isCheckedOut=false" ensures that the node is checked
> in after the operation. this way no extra operation needs to be
> implemented.
>
> the existence of the "jcr:isCheckedOut" property could also indicate
> that the client is well aware that he deals with a versionable node,
> so could a
> post to a checked in node, together with a jcr:isCheckedOut property
> always succeed (in respect to versioning) and the property specifies
> the desired end-state. eg: posting to a checked-in node, together with
> a jcr:isCheckedOut=false, does a checkout-update-checkin operation.
>
> regards, toby
>
> 2009/7/19 Dominik Süß <do...@gmail.com>:
>> I think this might be an excelent example project and could come
>> along with
>> a detailed documentation to show several aspects of sling/JCR
>> programming as
>> the mentioned use of selectors and versioning.
>>
>> Best regards,
>> Dominik
>>
>> On Sun, Jul 19, 2009 at 11:33 AM, Ian Boston <ie...@tfd.co.uk> wrote:
>>
>>> We had the same use case, and so wrote a servlet to do this, using a
>>> selector (*.save )
>>> We also did *.versions to list versions ( with paging) and
>>> *.version to
>>> get a specific version.
>>> See [1]
>>>
>>> Would be happy to bring this over to Sling *if* the team thought
>>> it was a
>>> useful addition ?
>>> Ian
>>>
>>> [1]
>>> http://github.com/ieb/open-experiments/tree/d98103e2d5d25abbddffb3ce77627b500e454659/slingtests/osgikernel/bundles/resource/src/main/java/org/sakaiproject/kernel/resource/version
>>>
>>>
>>>
>>>
>>> On 17 Jul 2009, at 18:23, Alexander Klimetschek wrote:
>>>
>>> On Fri, Jul 17, 2009 at 6:52 PM, Peter Chiochetti<pc...@myzel.net>
>>> wrote:
>>>>
>>>>> - If so, can I avoid replicating all of the used functionality
>>>>> of slingPostServlet?
>>>>>
>>>>> Is there a way to wrap it in ESP, so that it only has to
>>>>> "checkout(); processPostInServlet(); checkin()" or such?
>>>>>
>>>>
>>>> It might make sense to add a checkin-after-save feature to the
>>>> Sling
>>>> POST servlet (eg. ":checkin").
>>>>
>>>> For now you can write your own SlingPostOperation "checkin" that
>>>> you
>>>> would call via
>>>>
>>>> curl -F":operation=checkin" http://host/content
>>>>
>>>> It would effectively do checkin and checkout in one step, because
>>>> that's what you typically do - this way you can continue with
>>>> normal
>>>> sling post calls. It should probably also ensure that the
>>>> mix:versionable mixin is set. An example usage would look like
>>>> this:
>>>>
>>>> curl -F"myprop=value" http://host/content
>>>> curl -F"anotherprop=foo" http://host/content
>>>> curl -F":operation=checkin" http://host/content // first version
>>>> created
>>>> curl -F"myprop=foobar" http://host/content
>>>> curl -F":operation=checkin" http://host/content // second
>>>> version
>>>> created
>>>> ...
>>>>
>>>> Regards,
>>>> Alex
>>>>
>>>> --
>>>> Alexander Klimetschek
>>>> alexander.klimetschek@day.com
>>>>
>>>
>>>
>>
Re: Versioning using the SlingPostServlet
Posted by Tobias Bocanegra <tr...@day.com>.
hi,
i think the sling post servlet should leverage the content storage
metaphor as much as possible, i.e. controlling the versioning
operations with normal properties. eg: providing a
"jcr:isCheckedOut=true" ensures that the node is checked out,
providing a "jcr:isCheckedOut=false" ensures that the node is checked
in after the operation. this way no extra operation needs to be
implemented.
the existence of the "jcr:isCheckedOut" property could also indicate
that the client is well aware that he deals with a versionable node,
so could a
post to a checked in node, together with a jcr:isCheckedOut property
always succeed (in respect to versioning) and the property specifies
the desired end-state. eg: posting to a checked-in node, together with
a jcr:isCheckedOut=false, does a checkout-update-checkin operation.
regards, toby
2009/7/19 Dominik Süß <do...@gmail.com>:
> I think this might be an excelent example project and could come along with
> a detailed documentation to show several aspects of sling/JCR programming as
> the mentioned use of selectors and versioning.
>
> Best regards,
> Dominik
>
> On Sun, Jul 19, 2009 at 11:33 AM, Ian Boston <ie...@tfd.co.uk> wrote:
>
>> We had the same use case, and so wrote a servlet to do this, using a
>> selector (*.save )
>> We also did *.versions to list versions ( with paging) and *.version to
>> get a specific version.
>> See [1]
>>
>> Would be happy to bring this over to Sling *if* the team thought it was a
>> useful addition ?
>> Ian
>>
>> [1]
>> http://github.com/ieb/open-experiments/tree/d98103e2d5d25abbddffb3ce77627b500e454659/slingtests/osgikernel/bundles/resource/src/main/java/org/sakaiproject/kernel/resource/version
>>
>>
>>
>>
>> On 17 Jul 2009, at 18:23, Alexander Klimetschek wrote:
>>
>> On Fri, Jul 17, 2009 at 6:52 PM, Peter Chiochetti<pc...@myzel.net> wrote:
>>>
>>>> - If so, can I avoid replicating all of the used functionality
>>>> of slingPostServlet?
>>>>
>>>> Is there a way to wrap it in ESP, so that it only has to
>>>> "checkout(); processPostInServlet(); checkin()" or such?
>>>>
>>>
>>> It might make sense to add a checkin-after-save feature to the Sling
>>> POST servlet (eg. ":checkin").
>>>
>>> For now you can write your own SlingPostOperation "checkin" that you
>>> would call via
>>>
>>> curl -F":operation=checkin" http://host/content
>>>
>>> It would effectively do checkin and checkout in one step, because
>>> that's what you typically do - this way you can continue with normal
>>> sling post calls. It should probably also ensure that the
>>> mix:versionable mixin is set. An example usage would look like this:
>>>
>>> curl -F"myprop=value" http://host/content
>>> curl -F"anotherprop=foo" http://host/content
>>> curl -F":operation=checkin" http://host/content // first version
>>> created
>>> curl -F"myprop=foobar" http://host/content
>>> curl -F":operation=checkin" http://host/content // second version
>>> created
>>> ...
>>>
>>> Regards,
>>> Alex
>>>
>>> --
>>> Alexander Klimetschek
>>> alexander.klimetschek@day.com
>>>
>>
>>
>
Re: Versioning using the SlingPostServlet
Posted by Dominik Süß <do...@gmail.com>.
I think this might be an excelent example project and could come along with
a detailed documentation to show several aspects of sling/JCR programming as
the mentioned use of selectors and versioning.
Best regards,
Dominik
On Sun, Jul 19, 2009 at 11:33 AM, Ian Boston <ie...@tfd.co.uk> wrote:
> We had the same use case, and so wrote a servlet to do this, using a
> selector (*.save )
> We also did *.versions to list versions ( with paging) and *.version to
> get a specific version.
> See [1]
>
> Would be happy to bring this over to Sling *if* the team thought it was a
> useful addition ?
> Ian
>
> [1]
> http://github.com/ieb/open-experiments/tree/d98103e2d5d25abbddffb3ce77627b500e454659/slingtests/osgikernel/bundles/resource/src/main/java/org/sakaiproject/kernel/resource/version
>
>
>
>
> On 17 Jul 2009, at 18:23, Alexander Klimetschek wrote:
>
> On Fri, Jul 17, 2009 at 6:52 PM, Peter Chiochetti<pc...@myzel.net> wrote:
>>
>>> - If so, can I avoid replicating all of the used functionality
>>> of slingPostServlet?
>>>
>>> Is there a way to wrap it in ESP, so that it only has to
>>> "checkout(); processPostInServlet(); checkin()" or such?
>>>
>>
>> It might make sense to add a checkin-after-save feature to the Sling
>> POST servlet (eg. ":checkin").
>>
>> For now you can write your own SlingPostOperation "checkin" that you
>> would call via
>>
>> curl -F":operation=checkin" http://host/content
>>
>> It would effectively do checkin and checkout in one step, because
>> that's what you typically do - this way you can continue with normal
>> sling post calls. It should probably also ensure that the
>> mix:versionable mixin is set. An example usage would look like this:
>>
>> curl -F"myprop=value" http://host/content
>> curl -F"anotherprop=foo" http://host/content
>> curl -F":operation=checkin" http://host/content // first version
>> created
>> curl -F"myprop=foobar" http://host/content
>> curl -F":operation=checkin" http://host/content // second version
>> created
>> ...
>>
>> Regards,
>> Alex
>>
>> --
>> Alexander Klimetschek
>> alexander.klimetschek@day.com
>>
>
>
Re: Versioning using the SlingPostServlet
Posted by Ian Boston <ie...@tfd.co.uk>.
We had the same use case, and so wrote a servlet to do this, using a
selector (*.save )
We also did *.versions to list versions ( with paging) and *.version
to get a specific version.
See [1]
Would be happy to bring this over to Sling *if* the team thought it
was a useful addition ?
Ian
[1] http://github.com/ieb/open-experiments/tree/d98103e2d5d25abbddffb3ce77627b500e454659/slingtests/osgikernel/bundles/resource/src/main/java/org/sakaiproject/kernel/resource/version
On 17 Jul 2009, at 18:23, Alexander Klimetschek wrote:
> On Fri, Jul 17, 2009 at 6:52 PM, Peter Chiochetti<pc...@myzel.net>
> wrote:
>> - If so, can I avoid replicating all of the used functionality
>> of slingPostServlet?
>>
>> Is there a way to wrap it in ESP, so that it only has to
>> "checkout(); processPostInServlet(); checkin()" or such?
>
> It might make sense to add a checkin-after-save feature to the Sling
> POST servlet (eg. ":checkin").
>
> For now you can write your own SlingPostOperation "checkin" that you
> would call via
>
> curl -F":operation=checkin" http://host/content
>
> It would effectively do checkin and checkout in one step, because
> that's what you typically do - this way you can continue with normal
> sling post calls. It should probably also ensure that the
> mix:versionable mixin is set. An example usage would look like this:
>
> curl -F"myprop=value" http://host/content
> curl -F"anotherprop=foo" http://host/content
> curl -F":operation=checkin" http://host/content // first version
> created
> curl -F"myprop=foobar" http://host/content
> curl -F":operation=checkin" http://host/content // second version
> created
> ...
>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com
Re: Versioning using the SlingPostServlet
Posted by Alexander Klimetschek <ak...@day.com>.
On Fri, Jul 17, 2009 at 6:52 PM, Peter Chiochetti<pc...@myzel.net> wrote:
> - If so, can I avoid replicating all of the used functionality
> of slingPostServlet?
>
> Is there a way to wrap it in ESP, so that it only has to
> "checkout(); processPostInServlet(); checkin()" or such?
It might make sense to add a checkin-after-save feature to the Sling
POST servlet (eg. ":checkin").
For now you can write your own SlingPostOperation "checkin" that you
would call via
curl -F":operation=checkin" http://host/content
It would effectively do checkin and checkout in one step, because
that's what you typically do - this way you can continue with normal
sling post calls. It should probably also ensure that the
mix:versionable mixin is set. An example usage would look like this:
curl -F"myprop=value" http://host/content
curl -F"anotherprop=foo" http://host/content
curl -F":operation=checkin" http://host/content // first version created
curl -F"myprop=foobar" http://host/content
curl -F":operation=checkin" http://host/content // second version created
...
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com