rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Franklin <m.ben.frank...@gmail.com>
Subject Re: CXF Rest + WS Data Model
Date Thu, 28 Mar 2013 13:06:01 GMT
On Wed, Mar 27, 2013 at 9:01 PM, Matt Franklin <m.ben.franklin@gmail.com> wrote:
> On Wed, Mar 27, 2013 at 8:15 PM, Erin Noe-Payne
> <erin.noe.payne@gmail.com> wrote:
>> On Wed, Mar 27, 2013 at 6:47 PM, Matt Franklin <m.ben.franklin@gmail.com>wrote:
>>
>>> On Wednesday, March 27, 2013, Erin Noe-Payne wrote:
>>>
>>> > On Wed, Mar 27, 2013 at 4:12 PM, Matt Franklin <m.ben.franklin@gmail.com
>>> <javascript:;>
>>> > >wrote:
>>> >
>>> > > On Wed, Mar 27, 2013 at 3:35 PM, Chris Geer <chris@cxtsoftware.com>
>>> > wrote:
>>> > > > On Wed, Mar 27, 2013 at 12:25 PM, Erin Noe-Payne
>>> > > > <erin.noe.payne@gmail.com>wrote:
>>> > > >
>>> > > >> On Wed, Mar 27, 2013 at 2:58 PM, Chris Geer <chris@cxtsoftware.com>
>>> > > wrote:
>>> > > >>
>>> > > >> > On Wed, Mar 27, 2013 at 11:50 AM, Matt Franklin <
>>> > > >> m.ben.franklin@gmail.com
>>> > > >> > >wrote:
>>> > > >> >
>>> > > >> > > On Wed, Mar 27, 2013 at 2:32 PM, Chris Geer <
>>> > chris@cxtsoftware.com>
>>> > > >> > wrote:
>>> > > >> > > > On Wed, Mar 27, 2013 at 11:27 AM, Matt Franklin
<
>>> > > >> > > m.ben.franklin@gmail.com>wrote:
>>> > > >> > > >
>>> > > >> > > >> On Wed, Mar 27, 2013 at 1:59 PM, Chris
Geer <
>>> > > chris@cxtsoftware.com>
>>> > > >> > > wrote:
>>> > > >> > > >> > On Wed, Mar 27, 2013 at 10:42 AM,
Erin Noe-Payne
>>> > > >> > > >> > <erin.noe.payne@gmail.com>wrote:
>>> > > >> > > >> >
>>> > > >> > > >> >> On Wed, Mar 27, 2013 at 1:16 PM,
Matt Franklin <
>>> > > >> > > >> m.ben.franklin@gmail.com
>>> > > >> > > >> >> >wrote:
>>> > > >> > > >> >>
>>> > > >> > > >> >> > On Thu, Mar 21, 2013 at 5:32
PM, Chris Geer <
>>> > > >> > chris@cxtsoftware.com
>>> > > >> > > >
>>> > > >> > > >> >> 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?


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

Mime
View raw message