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:57:06 GMT
On Thu, Mar 28, 2013 at 8:53 AM, Matt Franklin <m.ben.franklin@gmail.com>wrote:

> On Thu, Mar 28, 2013 at 11:45 AM, Chris Geer <chris@cxtsoftware.com>
> wrote:
> > 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
>
> 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
> >> >>>
> >>
>

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