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 Fri, 29 Mar 2013 15:55:39 GMT
On Fri, Mar 29, 2013 at 8:41 AM, Erin Noe-Payne <erin.noe.payne@gmail.com>wrote:

> On Thu, Mar 28, 2013 at 12:06 PM, Matt Franklin <m.ben.franklin@gmail.com
> >wrote:
>
> > On Thu, Mar 28, 2013 at 11:57 AM, Chris Geer <chris@cxtsoftware.com>
> > wrote:
> > > 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?
> >
> > 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
> > >> >> >>>
> > >> >>
> > >>
> >
>

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