On 8/13/08, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Hi Outta, > > Outta Sight schrieb: > > > I'm looking for an example of how to perform versioned POSTs (POST.esp) > and also how to access a list of these versions (versions.esp) for any node. > It seems that this sort of capability must be scripted using Sling scripts. > Does anybody have examples using Javascript? Because Sling is built on top > of a content repository where one of the primary features is versioning - > I'd like to know how to do this. you can use the JSP api directly in the script, so eg. node.checkin() should work.
> Currently the SlingPostServlet does not do versioning. This would be an > extension to be built in. > > Regarding versioning there are probably two use cases: > > * checkpointing - create a new version of the modified node > before modifying it > * versioning - create a new version of the modified node > after modifying it > > In addition, I think, the SlingPostServlet should automatically check out a > versionable node before modification if the nodes happens to be checked in. this is not always desired. for example if a node is checked in, it could also mean that it should not to be altered until explicitly checked-out. > It also needs to be discussed, whether the node remains checked out after > the operation or is checked in. Probably, it should be in the state it was > before the operation: If the node was checked in, it must be checked in > after the operation. If it was checked out, it must be checked out after the > operation. i think that the versioning operations: checkin, checkout, checkpoint, restore need separate operations with clear additional parameters. i think too much magic in this case is not desirable. > Regarding access to the versions: There are two cases again: > > * Access to a certain (known) version > * Listing all versions of a node > > The first case might be implemented by the resource resolver as noted in > another thread by supporting parametrized URLs of the form > http://host/path;v=1. in the case you have an entire site versioned this is not very practical, since the names of the versions of each node are different. what you probably want is some sort of time-based version selector, eg: http://host/path;vdate=2008-08-13T08:11:00 which selects the most recent version before that date. a rewriter could adjust all links to resources and other pages so that the entire site is 'put' into an old state. > > The second case could be handled by the JSON default get servlet, which > could be enhanced to return a list of the versions for a given node... i would issue a second request to the version history of that node....this provides much more information. regards, toby
