Stanton, my thoughts are inline...
On Thu, Feb 20, 2014 at 8:46 AM, Stanton Sievers <[email protected]>wrote:
> Thanks for the link.
>
> Based on that information and what I've found in PagesResource, I think
> cloning via a GET then POST could work with a few caveats.
>
> 1) POST /pages doesn't currently allow you to create a page for a user
> other than the current user which is currently a use case for cloning. I
> think this could be a simple addition to the current API by providing a
> userId param as we do with the templateId.
>
Flow question: why do you need to be able to clone a page to another user?
Isn't the use case to have a user clone either their own page or a page
that is shared with them? I'm sure I'm not considering a use case but I
can't think of it.
>
> 2) The PageService APIs currently being used to handle page creation don't
> handle subpages very well at all. I went through that exercise when fixing
> page cloning in DefaultPageService. The same changes would either need to
> happen for page creation server-side or the onus will be with the
> client-side to call POST /pages/{id}/subpages to make sure the subpages get
> populated properly.
>
The honest truth is that the REST API needs some serious thought/design. We
started off well but it kind of stalled for a few reasons. I want to make
sure the REST API is built for the future, not to match the backend.
>
> 3) There are likely caveats with region widgets as there are with
> subpages. If a region widget has been adding/moved/removed in a page or
> subpage, I'm not sure that would be reflected in the newly created page
> because it gets created from the given template layout.
>
> At the end of the day, I think the shortest path is to re-introduce the
> clone API and use the existing API in PageService to service the request.
>
> What do others think?
>
How would you suggest that looks like (.../page/<id>/clone as a POST???).
>
>
>
> On Thu, Feb 20, 2014 at 10:24 AM, Matt Franklin <[email protected]
> >wrote:
>
> > On Thu, Feb 20, 2014 at 6:37 AM, Stanton Sievers <[email protected]
> > >wrote:
> >
> > > Hi all,
> > >
> > > I've been working a lot with the page cloning functionality in Rave
> > > recently (you might have noticed). I've discovered a need to move the
> > > clone API to CXF so that the Page object returned from the clone page
> API
> > > matches the page object structure expected by API calls like updatePage
> > > which is currently implemented via CXF.
> > >
> > > I've done some investigating and I have some questions I'm hoping this
> > list
> > > could help answer. I've noticed that
> org.apache.rave.rest.PagesResource
> > > doesn't have a clone API currently. It used to have one but was
> removed
> > > with commit 1505802 with a comment of " update to Resource interfaces
> to
> > > support proposed api specification". I'm wondering why the clone API
> was
> > > removed from PagesResource. Did it move somewhere else? Can anyone
> > > elaborate on the mentioned "api specification".
> > >
> >
> > http://wiki.apache.org/rave/RESTAPI
> >
> > There were also a bunch of e-mail threads around the proper way to
> approach
> > this. If I remember right, there were some proponents for making clone a
> > combination of a GET and a POST of the page to the API. I think there
> are
> > some nuances in cloning that this might not cover though.
> >
> >
> > >
> > > I noticed that RAVE-924 [1] has been resolved and I don't see any other
> > > page related tasks in its parent, RAVE-910 [2].
> > >
> > > [1] https://issues.apache.org/jira/browse/RAVE-924
> > > [2] https://issues.apache.org/jira/browse/RAVE-910
> >
> >
> > We can add a new ticket to the parent if client side copying does not
> > accomplish what we need to do.
> >
> >
> > >
> > >
> > > Thanks,
> > > -Stanton
> > >
> >
>
