On Wed, Mar 27, 2013 at 4:12 PM, Matt Franklin <[email protected]>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 > >> > > >> > > >> > > >> >> > >> > > >> >> > >> > > >> >> > > >> > > >> >> > The hard part is how to deal with rendering. For this > "mode" > >> we > >> > > will > >> > > >> >> > need to export the Wookie iFrame URL (which is per-user), > the > >> > > >> >> > openSocial security token and the OpenSocial metadata. > These > >> > > require > >> > > >> >> > a User to be authenticated and should not be exposed across > >> > things > >> > > >> >> > like the OMDL or Page export. What would everyone think > about > >> > the > >> > > >> >> > following url for this case?: /api/pages/{id}?render=true > >> > > >> >> > > >> > > >> >> > >> > > >> >> My gut reaction is that I dont like having a query string > >> parameter > >> > > to > >> > > >> >> dictate this. It seems like it would be better for the > endpoint > >> to > >> > be > >> > > >> >> context aware somehow. Possibly check the request and deliver > the > >> > > >> >> render-ready data set if its coming from an authenticated rave > >> > user? > >> > > I > >> > > >> need > >> > > >> >> to think about that a bit more... > >> > > >> >> > >> > > >> > > >> > > >> > I agree with Erin, not a fan of the query string. I'd rather > see > >> > > >> > /api/pages/{id}/rendered or something similar. > >> > > >> > >> I also do not like /api/pages/{id}/rendered. Url parts should be > >> semantically representative of resources, not of state or action. > >> > >> I'm now thinking... > >> /api/pages/0 - this is a representation of the generic page for export > >> /api/users/erin/pages/0 - this is a representation of the page in the > >> context of user erin, with user-specific data needed for rendering > >> attached. > >> > > > > I like this in concept but let's play it out. Since all pages are user > > specific (I think) why would the user link be the rendered? Maybe we > don't > > have a /api/pages/?? > > > > What about something like /api/user/erin/renderedpages/0 > 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. > 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. > > > > > 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 know anything about any specific provider at > >> all. > >> > > >> > >> > > > > >> > > > ok > >> > > > > >> > > >> > >> > > >> > > >> > > >> >> > >> > > >> >> > >> > > >> >> > > >> > > >> >> > Since we want to be able to "bootstrap" the client MVC > >> framework > >> > > with > >> > > >> >> > a pre-fetched & serialized version of the "Page" we will > also > >> > need > >> > > to > >> > > >> >> > do the same translation between what is currently returned > from > >> > the > >> > > >> >> > service layer in both the server MVC and the REST API; which > >> > raises > >> > > >> >> > the question as to wether or not we just abstract all of > that > >> > > >> >> > functionality in the service layer and only expose the "web" > >> > model > >> > > >> >> > from that layer or do we create yet another layer to > translate > >> > from > >> > > >> >> > the current service to the web model? > >> > > >> >> > > >> > > >> >> > >> > > >> >> +0 from me. The work should definitely be happening in some > >> service > >> > > >> layer > >> > > >> >> and keep the controllers light. Beyond that I'm not sure what > >> will > >> > > end > >> > > >> up > >> > > >> >> being cleaner. > >> > > >> >> > >> > > >> >> > >> > > >> >> > > >> > > >> >> > Thoughts? > >> > > >> >> > > >> > > >> >> > >> > > >> > >> > > > >> > > >> >
