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 Wed, 27 Mar 2013 22:47:20 GMT
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.




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