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
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
>>
