On Thu, Mar 28, 2013 at 11:45 AM, Chris Geer <[email protected]> wrote: > 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
Fair enough > - 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. Sounds good > - 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...) I really think we need a mechanism for mapping arbitrary sets of pages. If, in my environment, I want to retrieve a set of pages for customers another set for each user's portal and a third set for a specific project, we should be able to handle that with the same resource class. I don't want to have to write API endpoints for each of these sets of pages. > - 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) Yeah, I was just trying to avoid having duplicate method declarations > - The should be a @Path attribute at the root Class node So maybe there is a /pages api that supports basic operations for page and another Context endpoint that supports retrieving render-ready pages with all operations like moving widgets, etc handled there. > - 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 >> >>> >>
