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 20:12:24 GMT
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
>> > > >> >
>> > > >> >>
>> > > >> >>
>> > > >> >> >
>> > > >> >> > 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.
>>
>
> I like this in concept but let's play it out. Since all pages are user
> specific (I think) why would the user link be the rendered? Maybe we don't
> have a /api/pages/??
>
> What about something like /api/user/erin/renderedpages/0

We also need to consider how to get the pages by context (IE Portal,
Profile, etc)


>
> 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 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
View raw message