On Wed, Mar 27, 2013 at 9:01 PM, Matt Franklin <[email protected]> wrote: > On Wed, Mar 27, 2013 at 8:15 PM, Erin Noe-Payne > <[email protected]> wrote: >> On Wed, Mar 27, 2013 at 6:47 PM, Matt Franklin >> <[email protected]>wrote: >> >>> On Wednesday, March 27, 2013, Erin Noe-Payne wrote: >>> >>> > On Wed, Mar 27, 2013 at 4:12 PM, Matt Franklin <[email protected] >>> <javascript:;> >>> > >wrote: >>> > >>> > > On Wed, Mar 27, 2013 at 3:35 PM, Chris Geer <[email protected]> >>> > wrote: >>> > > > On Wed, Mar 27, 2013 at 12:25 PM, Erin Noe-Payne >>> > > > <[email protected]>wrote: >>> > > > >>> > > >> On Wed, Mar 27, 2013 at 2:58 PM, Chris Geer <[email protected]> >>> > > wrote: >>> > > >> >>> > > >> > On Wed, Mar 27, 2013 at 11:50 AM, Matt Franklin < >>> > > >> [email protected] >>> > > >> > >wrote: >>> > > >> > >>> > > >> > > On Wed, Mar 27, 2013 at 2:32 PM, Chris Geer < >>> > [email protected]> >>> > > >> > wrote: >>> > > >> > > > On Wed, Mar 27, 2013 at 11:27 AM, Matt Franklin < >>> > > >> > > [email protected]>wrote: >>> > > >> > > > >>> > > >> > > >> On Wed, Mar 27, 2013 at 1:59 PM, Chris Geer < >>> > > [email protected]> >>> > > >> > > wrote: >>> > > >> > > >> > On Wed, Mar 27, 2013 at 10:42 AM, Erin Noe-Payne >>> > > >> > > >> > <[email protected]>wrote: >>> > > >> > > >> > >>> > > >> > > >> >> On Wed, Mar 27, 2013 at 1:16 PM, Matt Franklin < >>> > > >> > > >> [email protected] >>> > > >> > > >> >> >wrote: >>> > > >> > > >> >> >>> > > >> > > >> >> > On Thu, Mar 21, 2013 at 5:32 PM, Chris Geer < >>> > > >> > [email protected] >>> > > >> > > > >>> > > >> > > >> >> wrote: >>> > > >> > > >> >> > > I've done a first cut at adding some new CXF based >>> REST >>> > > web >>> > > >> > > services >>> > > >> > > >> >> > which >>> > > >> > > >> >> > > use a different data model >>> > > >> > > >> >> > >>> > > >> > > >> >> > As part of RAVE-924, I have created a new page model for >>> > > web. >>> > > >> > As I >>> > > >> > > >> >> > was building it, it occurred to me that there are a >>> couple >>> > > of >>> > > >> > > >> >> > different ways we will want/need to use the REST >>> interface >>> > > for >>> > > >> > > Page: >>> > > >> > > >> >> > >>> > > >> > > >> >> > 1) As an export mechanism >>> > > >> > > >> >> > 2) As an OMDL export mechanism >>> > > >> > > >> >> > 3) As an entry point for applications who want to render >>> > > >> widgets >>> > > >> > > >> >> > (including the portal) >>> > > >> > > >> >> > >>> > > >> > > >> >> > IMO, #1 is straight forward. For number 2, I was >>> thinking >>> > > that >>> > > >> > it >>> > > >> > > >> >> > would be better if there was an OMDL mime type so the >>> > > logical >>> > > >> > > mapping >>> > > >> > > >> >> > remains the same (/api/pages/{id}) as in the regular >>> > export. >>> > > >> > What >>> > > >> > > >> >> > does everyone think about using >>> application/vnd.omdl+xml? >>> > > >> > > >> >> > >>> > > >> > > >> >> >>> > > >> > > >> >> +1 here, I think mime type is the right approach. I have >>> no >>> > > >> opinion >>> > > >> > > on >>> > > >> > > >> the >>> > > >> > > >> >> actual label of the mime type - that looks fine. >>> > > >> > > >> >> >>> > > >> > > >> > >>> > > >> > > >> > +1 >>> > > >> > > >> > >>> > > >> > > >> >> >>> > > >I don't think pages are user-specific, they just have a relationship >>> to >>> > users. They are still a first class resource in rave and should be >>> > accessible independent of user, so /api/pages should remain imo. There's >>> > nothing wrong with having multiple api routes to arrive at the same >>> > resource. >>> > >>> > >>> +1 >>> >>> >>> > >>> > > We also need to consider how to get the pages by context (IE Portal, >>> > > Profile, etc) >>> > >>> > >>> > what do you mean by this? Filtering the data set by a property? Portal, >>> > profile or whatever else are just a property of the page. >>> >>> >>> Yes, but to build the portal, you will need to request all pages for a user >>> in the portal context. In the profile, you will need to do the same in >>> that context. This extends to any context that developers want to support. >>> >>> >>> >> So I think that's just looks like filtering. Simplest way is query string >> and strict matching. >> /api/users/erin/pages?type=portal > > I agree with the query string parameter for filtering, but I am not > sure the /users/username model works in all cases. What if I wanted > to have pages that represent a project or collaboration workspace? I > think it could work if we abstract it to: > > /api/{context}/{identifier}/pages > > this would give us > > /api/portal/erin/pages for Erin's portal pages > /api/profile/erin/pages for Erin's profile pages > /api/projects/work/pages for all pages related to the "Work" project > /api/groups/coolio/pages for all pages beloning to the coolio group, etc
I have committed a PageResource that reflects this. Can everyone take a look and provide feedback. Also, it appears that in CXF you can't have multiple paths to the same method. As many of these operations don't really need the context identifiers, is there a way to not duplicate method declarations? > > there would be no need for the type parameter at that point. > >> >> If we see a need we could potentially support a more complex querying >> syntax. I've always been a little unclear about how this jives with REST >> though... >> >> Whatever we do though shouldn't be a specific solution for pages but a >> general way of filtering data sets. >> >> >>> >>> > >>> > >>> > > >>> > > > >>> > > > That would make it a resource and make more sense. >>> > > > >>> > > > Chris >>> > > > >>> > > >> >>> > > >> >>> > > >> > > >> > >>> > > >> > > >> > Is the intent to return the wookie and OS stuff in the same >>> > > >> > response? >>> > > >> > > I'm >>> > > >> > > >> > not a fan of that, especially considering some people won't >>> > > have >>> > > >> > > wookie >>> > > >> > > >> > installed at all (or OS). >>> > > >> > > >> >>> > > >> > > >> The approach I was going to take is to inject all the >>> providers >>> > > in >>> > > >> the >>> > > >> > > >> current context into a service and when the render condition >>> is >>> > > hit, >>> > > >> > > >> have the provider return an object that extends the 'core' >>> > > >> > > >> RegionWidget with its own properties. This way, there is no >>> > > >> coupling >>> > > >> > > >> to any specific provider. You would be able to have 0...n >>> > > >> providers. >>> > > >> > > >> >>> > > >> > > >> >Maybe it makes more sense to have a different web >>> > > >> > > >> > service for rendering by each provider??? >>> > > >> > > >> >>> > > >> > > >> This will end up causing serious performance bottlenecks in >>> an >>> > > >> already >>> > > >> > > >> taxed system. >>> > > >> > > >> >>> > > >> > > > >>> > > >> > > > I don't understand this comment. How would this cause serious >>> > > >> > performance >>> > > >> > > > bottlenecks? Having additional services won't cause any >>> > problems, >>> > > and >>> > > >> > > they >>> > > >> > > > should only be called when they are used which would be no >>> > > more/less >>> > > >> > than >>> > > >> > > > if it was a single service. I'm ok not doing this, just not >>> sure >>> > > what >>> > > >> > > would >>> > > >> > > > cause the major performance problems you are referring to. >>> > > >> > > >>> > > >> > > I should have been more clear. As we move away from server-side >>> > > >> > > templating to client-side MVC to deliver the OOTB interface, >>> these >>> > > >> > > services will be used by the framework we have running in the >>> > > browser. >>> > > >> > > If it has to make AJAX calls for each widget to get the >>> necessary >>> > > >> > > information to render the widget, we are going to end up with a >>> > > bunch >>> > > >> > > of extra AJAX calls in order to initiate rendering of the the >>> > > widgets >>> > > >> > > on a page. Since widgets are already iFrames and require their >>> > own >>> > > >> > > set of round trips to the widget provider, we now end up in a >>> > > >> > > situation we have even more network requests to services. >>> > > >> > > >>> > > >> > > My thought in returning this information as part of the initial >>> > page >>> > > >> > > REST call is that we can eliminate the extra round trips to the >>> > > server >>> > > >> > > to get the provider representation of the widget. >>> > > >> > > >>> > > >> > >>> > > >> > That makes sense. The only thing I want to make sure we can do >>> > > >> dynamically >>> > > >> > add (reload) a gadget to a page without re-rendering the whole >>> page. >>> > > >> > >>> > > >> >>> > > >> Absolutely agree. This approach is in line with that goal. The basic >>> > > >> mechanism would be that the page loads with it's initial state >>> > > >> (bootstrapped data we are discussing now). If a user adds a new >>> widget >>> > > then >>> > > >> the client side state is updated and appropriate rendering happens, >>> as >>> > > well >>> > > >> as a post to server to update server side state; no page reload >>> > happens. >>> > > >> >>> > > >> >>> > > >> > >>> > > >> > > >>> > > >> > > > >>> > > >> > > >> >>> > > >> > > >> >Otherwise this "core" service has >>> > > >> > > >> > to know about all the different providers which can be a >>> > > problem >>> > > >> > > moving >>> > > >> > > >> > forward. >>> > > >> > > >> >>> > > >> > > >> It shouldn't have to >>>
