I mostly agree. Page creation today is template based in most (all?) cases, which loses region widget changes as I mentioned earlier. It sounds like there is a bug with the APIs for creating a new page where they should be handling subpages and region widgets differently and not just populating them from the template.
On Thu, Feb 20, 2014 at 12:42 PM, Erin Noe-Payne <[email protected]>wrote: > The original intention was that cloning a page is just creating a new > page. To the extent that there are caveats or complications with > cloning a page, it mostly seems like those are things that need to be > handled by page creation anyway. > > 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? > > > >> > >> > > >> > 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. > > > > > >> > >> > > >> > > >> > > >> > 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 > >> > > > > >> > > > >> > > >> >
