On Thu, Mar 28, 2013 at 8:53 AM, Matt Franklin <[email protected]>wrote:
> 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. > So instead of /portal it would be /context/portal? That would work. Again, the only thing that doesn't allow for is unique methods for each context in the future...but maybe that's not a big deal. I guess I still don't see how contexts are really used so I'm not grasping the importance. Is this essentially a replacement for pageType? How would it work exactly? > > > - 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 > >> >>> > >> >
