rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Geer <ch...@cxtsoftware.com>
Subject Re: CXF Rest + WS Data Model
Date Thu, 28 Mar 2013 15:45:53 GMT
On Thu, Mar 28, 2013 at 6:06 AM, Matt Franklin <m.ben.franklin@gmail.com>wrote:

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

Few comments:
 - Naming:
    - I believe we should name the resource classes after the path (so
plural) i.e. PagesResource
    - 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.
 - 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...)
   - 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)
   - The should be a @Path attribute at the root Class node
   - 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
> >>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message