You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Tomek Rękawek <to...@cognifide.com> on 2015/01/26 10:25:47 UTC
Re: Sling CRUD with content versioning, API architecture
Hello,
the topic has been moved from the Sling Users List, as we went from support
to development :)
On Thu, Jan 15, 2015 at 3:08 PM, Bertrand Delacretaz wrote:
> On Thu, Jan 15, 2015 at 3:38 PM, Robert Munteanu <ro...@...> wrote:
> > ...You _might_ be able to get away with creating a new resource provider,
> > based on the jcr resource provider....
(...)
This comes up from time to time but for some reason it seems like no
> one needed this enough to implement it so far. But that would be a
> good addition to Sling IMO.
Last week I spend some time on implementing the versioning support.
Creating new version was already possible (via :operation=checkin and
checkout), so to complete the support I added 3 features:
1. Returning given version of the resource via semicolon-separated
parameters
It was already discussed 5 years ago in the SLING-848. I added the
parameters support in ResourceResolver and modified the JcrResourceResolver
to handle the v parameter. More info on the implementation and the pull
request can be found in the JIRA comment [1].
2. Listing all versions
Bertrand suggested that new GET servlet bound to V selector and json
extension could display all versions. I implemented this as a part of the
SLING-4318. Pull request and description in JIRA comment [2].
3. Restoring old version
I added new SlingPostServlet operation [3] to restore a version referenced
by its number or label. Implemented as a part of the SLING-4318. Pull
request and description in the same comment as above [2].
Looking forward to some feedback, especially from people involved in the
previous discussions on Sling Users and JIRA-848.
[1]
https://issues.apache.org/jira/browse/SLING-848?focusedCommentId=14288340
[2]
https://issues.apache.org/jira/browse/SLING-4318?focusedCommentId=14289243
[3]
http://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#slingpostservlet-operations
Best regards,
Tomek
--
Tomek Rękawek
Senior Software Engineer
Cognifide Polska Sp. z o.o.
skype: trekawek
www.cognifide.com
Re: Sling CRUD with content versioning, API architecture
Posted by Tomek Rękawek <to...@cognifide.com>.
On Mon, Jan 26, 2015 at 1:45 PM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
>
> > ...The request-aware method is already marked as
> > deprecated since 2.2.0 and there is a Javadoc stating that this method
> > won't be invoked anymore....
>
> Ok, you're right that this is not needed then.
>
I commited the updated, backward-compatible version of SLING-848 (with the
new Parametrizable interface) and the future-proof version of SLING-4318
(with versions wrapped in {}).
Thanks for the suggestions. Any other thoughts?
Regards,
Tomek
--
Tomek Rękawek
Senior Software Engineer
Cognifide Polska Sp. z o.o.
skype: trekawek
www.cognifide.com
Re: Sling CRUD with content versioning, API architecture
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Jan 26, 2015 at 12:32 PM, Tomek Rękawek
<to...@cognifide.com> wrote:
> On Mon, Jan 26, 2015 at 11:57 AM, Bertrand Delacretaz <
> bdelacretaz@apache.org> wrote:
>> ...Shouldn't PRP also extend getResource(ResourceResolver,
>> HttpServletRequest, String) ?
>>
> ...The request-aware method is already marked as
> deprecated since 2.2.0 and there is a Javadoc stating that this method
> won't be invoked anymore....
Ok, you're right that this is not needed then.
-Bertrand
Re: Sling CRUD with content versioning, API architecture
Posted by Tomek Rękawek <to...@cognifide.com>.
Hi Bertrand,
On Mon, Jan 26, 2015 at 11:57 AM, Bertrand Delacretaz <
bdelacretaz@apache.org> wrote:
>
> > ....How about creating ParametrizableResourceProvider with the extended
> get()
> > method? If there are some parameters and the ResourceProvider implements
> > also PRP, the resource resolver will invoke the new get() method...
>
> Shouldn't PRP also extend getResource(ResourceResolver,
> HttpServletRequest, String) ?
>
I'm not sure about this. The request-aware method is already marked as
deprecated since 2.2.0 and there is a Javadoc stating that this method
won't be invoked anymore. Do we want to burden the new interface with this
legacy?
Regards,
Tomek
--
Tomek Rękawek
Senior Software Engineer
Cognifide Polska Sp. z o.o.
skype: trekawek
www.cognifide.com
Re: Sling CRUD with content versioning, API architecture
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Tomek,
On Mon, Jan 26, 2015 at 11:43 AM, Tomek Rękawek
<to...@cognifide.com> wrote:
> On Mon, Jan 26, 2015 at 11:02 AM, Bertrand Delacretaz <
> bdelacretaz@apache.org> wrote:
>> About https://github.com/apache/sling/pull/57, the URI parameters, is
>> there an alternative that avoids modifying the ResourceProvider
>> interface?...
> ....How about creating ParametrizableResourceProvider with the extended get()
> method? If there are some parameters and the ResourceProvider implements
> also PRP, the resource resolver will invoke the new get() method...
Sounds good to me.
> ...The PRP would be an extending interface (like
> AttributableResourceProvider), not a replacement for the RP....
Ok.
Shouldn't PRP also extend getResource(ResourceResolver,
HttpServletRequest, String) ?
-Bertrand
Re: Sling CRUD with content versioning, API architecture
Posted by Tomek Rękawek <to...@cognifide.com>.
Hello Bertrand,
On Mon, Jan 26, 2015 at 11:02 AM, Bertrand Delacretaz <
bdelacretaz@apache.org> wrote:
>
> I have commented in SLING-4318, about making the SLING-848 URIs
> discoverable.
>
Thanks for the suggestion, I'll move the versions to a new subtree so we
can extend the JSON in the future.
> About https://github.com/apache/sling/pull/57, the URI parameters, is
> there an alternative that avoids modifying the ResourceProvider
> interface? There's probably lots of ResourceProvider in the field, so
> maybe creating a child ResourceProvider2 interface would be less
> disruptive?
>
How about creating ParametrizableResourceProvider with the extended get()
method? If there are some parameters and the ResourceProvider implements
also PRP, the resource resolver will invoke the new get() method. Otherwise
it'll stick to the old one.
The PRP would be an extending interface (like
AttributableResourceProvider), not a replacement for the RP.
Regards,
Tomek
--
Tomek Rękawek
Senior Software Engineer
Cognifide Polska Sp. z o.o.
skype: trekawek
www.cognifide.com
Re: Sling CRUD with content versioning, API architecture
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Tomek,
This looks very interesting, thanks!
I have commented in SLING-4318, about making the SLING-848 URIs discoverable.
About https://github.com/apache/sling/pull/57, the URI parameters, is
there an alternative that avoids modifying the ResourceProvider
interface? There's probably lots of ResourceProvider in the field, so
maybe creating a child ResourceProvider2 interface would be less
disruptive?
-Bertrand