On Thu, Mar 28, 2013 at 6:06 AM, Matt Franklin <[email protected]>wrote:
> 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? > Few comments: - Naming: - I believe we should name the resource classes after the path (so plural) i.e. PagesResource - XML, we need a consensus on naming XML Elements. My personal belief is attributes are camelCase and elements are PascalCase (in the XML attribute tags). Right now we have a mix. - No, you can't have multiple paths for the same method - My personal belief is we should have a resource for each root path (/people, /pages, /portal, /profile...) - If functionality overlaps between methods in those classes it can be abstracted out to a service which is shared between them (or simple utility class) - The should be a @Path attribute at the root Class node - This also allows us to have unique methods for each context later down the road > > > > > > 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 > >>> >
