On Fri, Mar 29, 2013 at 8:41 AM, Erin Noe-Payne <[email protected]>wrote:
> On Thu, Mar 28, 2013 at 12:06 PM, Matt Franklin <[email protected] > >wrote: > > > On Thu, Mar 28, 2013 at 11:57 AM, Chris Geer <[email protected]> > > wrote: > > > 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? > > > > I do see it as a step toward replacing the current "PageType" system. > > The problem I am really trying to solve is that when we use rave in > > ${work}, I have to create custom controllers to deliver pages for > > things like customers or project portfolios. IMO, this is severely > > limiting and if we could use this generic context/identifier mapping > > to let us query for the right set of pages from the database, we can > > more easily support any type of conceptual subject. > > > > > I had to think about it for a while, but I'm +1 for this approach with > generically definable {context}/{identifier}. A minor comment is that when > we talk about delivering a a full renderable page with all associated data > - context, authenticated user, widget render & metadata - I feel like we > are breaking from rest. Is that true? In that case would it make more sense > to put these routes not under the api? Under this model... > > /api/... restful api that delivers resources > /{context}/{identifier}/pages - application routes. With accept headers of > html, delivers the html page with bootstrapped data. with accept headers of > json, delivers just the json data representation. > I like the use of accept headers to drive what is returned. Since we need a root path can we do /contexts/{context}/...? > > > > > >> > > >> > - 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 > > >> >> >>> > > >> >> > > >> > > >
