On Wed, Mar 27, 2013 at 5: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 have no problem with the query param in this case but I still don't understand the need. How can the same page be rendered differently? Given a single page definition, what would be different when rendered via type portal vs profile? > > 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 > > >
