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 Wed, 27 Mar 2013 18:58:10 GMT
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.
> >> >
> >> > 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.

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