Sorry, I wasn't very clear. The "Share Page" dialog not only allows you to
share a page with a user (and optionally give them edit permissions) but
also to create a new clone for a user instead of giving them access to the
existing instance.
I agree on the REST API not having actions in the path. POST could be
implemented on /pages/{id} as a clone action, but that seems pretty weak
semantically to me.
On Thu, Feb 20, 2014 at 12:43 PM, Chris Geer <[email protected]> wrote:
> On Thu, Feb 20, 2014 at 10:17 AM, Stanton Sievers <[email protected]
> >wrote:
>
> > Responses inline
> >
> >
> > On Thu, Feb 20, 2014 at 11:12 AM, Chris Geer <[email protected]>
> > wrote:
> >
> > > 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.
> > >
> >
> > Unless I'm mistaken you can clone a page to another user in the "Share
> > Page" dialog in the default portal today. Is this not a desired use case
> > or is it being deprecated? Am I misunderstanding the "New" link of the
> > "Share Page" dialog?
> >
>
> Oh, that's not at all how I understood "Share Page" to work. In my mind,
> cloning and sharing are two very different things. Clone to me mean, make a
> completely separate copy. Share mean, share the page so that when the owner
> makes a change, the person it was shared with see that change.
>
> Now, I'm not sure how it's actually implemented but above is how I thought
> it should work.
>
> >
> > >
> > > >
> > > > 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.
> > >
> >
> > I agree. I'm not in a great position yet to understand the future
> > direction for the REST API, but I'll be happy to participate in those
> > discussions to ensure that any work I do in this area matches the
> > direction.
> >
> >
> > >
> > > >
> > > > 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???).
> > >
> >
> > Perhaps. I hadn't thought through what the API call would actually look
> > like, but that seems reasonable if that's the direction we want to go in.
> >
>
> I'm not a fan of that approach actually because I lean more towards the
> "purist" REST view than many. I'm not a fan of having actions as part of
> the URL structure whenever possible. I need to think about how we might
> structure this so we can achieve a clone effect while still keeping the url
> structure. Maybe it's not possible.
>
> >
> >
> > >
> > > >
> > > >
> > > >
> > > > 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
> > > > > >
> > > > >
> > > >
> > >
> >
>
