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 Wed, 27 Mar 2013 19:25:50 GMT
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
> > >> >
> > >> >>
> > >> >>
> > >> >> >
> > >> >> > The hard part is how to deal with rendering.  For this "mode"
we
> > will
> > >> >> > need to export the Wookie iFrame URL (which is per-user),
the
> > >> >> > openSocial security token and the OpenSocial metadata.  These
> > require
> > >> >> > a User to be authenticated and should not be exposed across
> things
> > >> >> > like the OMDL or Page export.  What would everyone think
about
> the
> > >> >> > following url for this case?:  /api/pages/{id}?render=true
> > >> >> >
> > >> >>
> > >> >> My gut reaction is that I dont like having a query string parameter
> > to
> > >> >> dictate this. It seems like it would be better for the endpoint
to
> be
> > >> >> context aware somehow. Possibly check the request and deliver
the
> > >> >> render-ready data set if its coming from an authenticated rave
> user?
> > I
> > >> need
> > >> >> to think about that a bit more...
> > >> >>
> > >> >
> > >> > I agree with Erin, not a fan of the query string. I'd rather see
> > >> > /api/pages/{id}/rendered or something similar.
>

I also do not like /api/pages/{id}/rendered.  Url parts should be
semantically representative of resources, not of state or action.

I'm now thinking...
/api/pages/0 - this is a representation of the generic page for export
/api/users/erin/pages/0 - this is a representation of the page in the
context of user erin, with user-specific data needed for rendering attached.


> > >> >
> > >> > 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 know anything about any specific provider at all.
> > >>
> > >
> > > ok
> > >
> > >>
> > >> >
> > >> >>
> > >> >>
> > >> >> >
> > >> >> > Since we want to be able to "bootstrap" the client MVC framework
> > with
> > >> >> > a pre-fetched & serialized version of the "Page" we will
also
> need
> > to
> > >> >> > do the same translation between what is currently returned
from
> the
> > >> >> > service layer in both the server MVC and the REST API; which
> raises
> > >> >> > the question as to wether or not we just abstract all of
that
> > >> >> > functionality in the service layer and only expose the "web"
> model
> > >> >> > from that layer or do we create yet another layer to translate
> from
> > >> >> > the current service to the web model?
> > >> >> >
> > >> >>
> > >> >> +0 from me. The work should definitely be happening in some service
> > >> layer
> > >> >> and keep the controllers light. Beyond that I'm not sure what
will
> > end
> > >> up
> > >> >> being cleaner.
> > >> >>
> > >> >>
> > >> >> >
> > >> >> > Thoughts?
> > >> >> >
> > >> >>
> > >>
> >
>

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