rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erin Noe-Payne <erin.noe.pa...@gmail.com>
Subject Re: CXF Rest + WS Data Model
Date Fri, 29 Mar 2013 15:41:03 GMT
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.

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