You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by Chris Geer <ch...@cxtsoftware.com> on 2013/03/21 22:32:36 UTC
CXF Rest + WS Data Model
I've done a first cut at adding some new CXF based REST web services which
use a different data model and uploaded a patch to the ticket [1]. I tried
to upload to Review Board but it was too big I think. The biggest change is
I had to relocate all the model interfaces from
rave-core/org.apache.rave.portal.model ->
rave-core-api/org.apache.rave.model. We would have to had do
it eventually but I needed to do it now to build the conversions between
the models. One nice thing is that the web services support partial data
objects so we can limit fields on retrieval for security reasons and we can
accept partial updates.
At this point I'd like to commit this small step because I don't want to
get into a situation where the model is being changes in trunk in the old
location and by me in the new location which will cause major merge issues.
If there are any objections I can move all these changes to a branch and we
can deal with the merge issues later.
Chris
[1] https://issues.apache.org/jira/browse/RAVE-910
Re: CXF Rest + WS Data Model
Posted by Chris Geer <ch...@cxtsoftware.com>.
On Fri, Mar 29, 2013 at 8:41 AM, Erin Noe-Payne <er...@gmail.com>wrote:
> 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 <ch...@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 <ch...@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
> > >> >> > <er...@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
> > >> >> >>> > > > <er...@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
> > >> >> >>> > > >> > > >> > <er...@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.
>
I like the use of accept headers to drive what is returned. Since we need a
root path can we do /contexts/{context}/...?
>
> >
> > >>
> > >> > - 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
> > >> >> >>>
> > >> >>
> > >>
> >
>
Re: CXF Rest + WS Data Model
Posted by Erin Noe-Payne <er...@gmail.com>.
On Fri, Mar 29, 2013 at 4:47 PM, Matt Franklin <m....@gmail.com>wrote:
> >
> >
> > 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...
> >
>
> I don't think it breaks rest. It is still a representation of the
> resource.
>
>
> >
> > /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.
> >
> >
> I can see where you are going with this, but I would like this capability
> in "core" and think view matching & other MVC pieces are part of an
> implementation, like the OOTB portal. I would be ok with a separate
> contexts API though that delivers the rendered pages.
>
> Sot that we are not totally talking in abstract, I have committed enough of
> the pieces for us to look at the render-ready/export-ready versions of the
> pages. Paths are by no means "correct" or final:
>
> Some examples of current functionality:
>
> /api/rest/pages/{pageId} Returns the export
> version of the page with the specified id
> /api/rest/pages/portal/@self Returns all portal pages
> for the currently authenticated principal (user)
> /api/rest/pages/portal/@self/{pageId} Returns the portal page with
> the Id of pageId for the currently authenticated principal (user)
> /api/rest/pages/portal/{userId} Returns all portal pages
> for the userId
> /api/rest/pages/profile/{userId} Returns all profile pages
> for the userId
>
I like this a lot. +1.
Re: CXF Rest + WS Data Model
Posted by Matt Franklin <m....@gmail.com>.
>
>
> 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...
>
I don't think it breaks rest. It is still a representation of the resource.
>
> /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.
>
>
I can see where you are going with this, but I would like this capability
in "core" and think view matching & other MVC pieces are part of an
implementation, like the OOTB portal. I would be ok with a separate
contexts API though that delivers the rendered pages.
Sot that we are not totally talking in abstract, I have committed enough of
the pieces for us to look at the render-ready/export-ready versions of the
pages. Paths are by no means "correct" or final:
Some examples of current functionality:
/api/rest/pages/{pageId} Returns the export
version of the page with the specified id
/api/rest/pages/portal/@self Returns all portal pages
for the currently authenticated principal (user)
/api/rest/pages/portal/@self/{pageId} Returns the portal page with
the Id of pageId for the currently authenticated principal (user)
/api/rest/pages/portal/{userId} Returns all portal pages
for the userId
/api/rest/pages/profile/{userId} Returns all profile pages
for the userId
Re: CXF Rest + WS Data Model
Posted by Erin Noe-Payne <er...@gmail.com>.
On Thu, Mar 28, 2013 at 12:06 PM, Matt Franklin <m....@gmail.com>wrote:
> On Thu, Mar 28, 2013 at 11:57 AM, Chris Geer <ch...@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 <ch...@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
> >> >> > <er...@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
> >> >> >>> > > > <er...@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
> >> >> >>> > > >> > > >> > <er...@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
> >> >> >>>
> >> >>
> >>
>
Re: CXF Rest + WS Data Model
Posted by Matt Franklin <m....@gmail.com>.
On Thu, Mar 28, 2013 at 11:57 AM, Chris Geer <ch...@cxtsoftware.com> wrote:
> On Thu, Mar 28, 2013 at 8:53 AM, Matt Franklin <m....@gmail.com>wrote:
>
>> On Thu, Mar 28, 2013 at 11:45 AM, Chris Geer <ch...@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
>> >> > <er...@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
>> >> >>> > > > <er...@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
>> >> >>> > > >> > > >> > <er...@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.
>
>>
>> > - 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
>> >> >>>
>> >>
>>
Re: CXF Rest + WS Data Model
Posted by Chris Geer <ch...@cxtsoftware.com>.
On Thu, Mar 28, 2013 at 8:53 AM, Matt Franklin <m....@gmail.com>wrote:
> On Thu, Mar 28, 2013 at 11:45 AM, Chris Geer <ch...@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
> >> > <er...@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
> >> >>> > > > <er...@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
> >> >>> > > >> > > >> > <er...@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?
>
> > - 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
> >> >>>
> >>
>
Re: CXF Rest + WS Data Model
Posted by Matt Franklin <m....@gmail.com>.
On Thu, Mar 28, 2013 at 11:45 AM, Chris Geer <ch...@cxtsoftware.com> wrote:
> On Thu, Mar 28, 2013 at 6:06 AM, Matt Franklin <m....@gmail.com>wrote:
>
>> On Wed, Mar 27, 2013 at 9:01 PM, Matt Franklin <m....@gmail.com>
>> wrote:
>> > On Wed, Mar 27, 2013 at 8:15 PM, Erin Noe-Payne
>> > <er...@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
>> >>> > > > <er...@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
>> >>> > > >> > > >> > <er...@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.
> - 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
>> >>>
>>
Re: CXF Rest + WS Data Model
Posted by Chris Geer <ch...@cxtsoftware.com>.
On Thu, Mar 28, 2013 at 6:06 AM, Matt Franklin <m....@gmail.com>wrote:
> On Wed, Mar 27, 2013 at 9:01 PM, Matt Franklin <m....@gmail.com>
> wrote:
> > On Wed, Mar 27, 2013 at 8:15 PM, Erin Noe-Payne
> > <er...@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
> >>> > > > <er...@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
> >>> > > >> > > >> > <er...@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
- 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.
- 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...)
- 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)
- The should be a @Path attribute at the root Class node
- 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
> >>>
>
Re: CXF Rest + WS Data Model
Posted by Matt Franklin <m....@gmail.com>.
On Wed, Mar 27, 2013 at 9:01 PM, Matt Franklin <m....@gmail.com> wrote:
> On Wed, Mar 27, 2013 at 8:15 PM, Erin Noe-Payne
> <er...@gmail.com> wrote:
>> On Wed, Mar 27, 2013 at 6:47 PM, Matt Franklin <m....@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 <ch...@cxtsoftware.com>
>>> > wrote:
>>> > > > On Wed, Mar 27, 2013 at 12:25 PM, Erin Noe-Payne
>>> > > > <er...@gmail.com>wrote:
>>> > > >
>>> > > >> On Wed, Mar 27, 2013 at 2:58 PM, Chris Geer <ch...@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
>>> > > >> > > >> > <er...@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?
>
> 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
>>>
Re: CXF Rest + WS Data Model
Posted by Matt Franklin <m....@gmail.com>.
On Wed, Mar 27, 2013 at 8:15 PM, Erin Noe-Payne
<er...@gmail.com> wrote:
> On Wed, Mar 27, 2013 at 6:47 PM, Matt Franklin <m....@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 <ch...@cxtsoftware.com>
>> > wrote:
>> > > > On Wed, Mar 27, 2013 at 12:25 PM, Erin Noe-Payne
>> > > > <er...@gmail.com>wrote:
>> > > >
>> > > >> On Wed, Mar 27, 2013 at 2:58 PM, Chris Geer <ch...@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
>> > > >> > > >> > <er...@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
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
>>
Re: CXF Rest + WS Data Model
Posted by Chris Geer <ch...@cxtsoftware.com>.
On Wed, Mar 27, 2013 at 5:15 PM, Erin Noe-Payne <er...@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 <ch...@cxtsoftware.com>
> > > wrote:
> > > > > On Wed, Mar 27, 2013 at 12:25 PM, Erin Noe-Payne
> > > > > <er...@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
> > > > >> > > >> > <er...@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 have no problem with the query param in this case but I still don't
understand the need. How can the same page be rendered differently? Given a
single page definition, what would be different when rendered via type
portal vs profile?
>
> 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
> >
>
Re: CXF Rest + WS Data Model
Posted by Erin Noe-Payne <er...@gmail.com>.
On Wed, Mar 27, 2013 at 6:47 PM, Matt Franklin <m....@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 <ch...@cxtsoftware.com>
> > wrote:
> > > > On Wed, Mar 27, 2013 at 12:25 PM, Erin Noe-Payne
> > > > <er...@gmail.com>wrote:
> > > >
> > > >> On Wed, Mar 27, 2013 at 2:58 PM, Chris Geer <ch...@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
> > > >> > > >> > <er...@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
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
>
Re: CXF Rest + WS Data Model
Posted by Matt Franklin <m....@gmail.com>.
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 <ch...@cxtsoftware.com>
> wrote:
> > > On Wed, Mar 27, 2013 at 12:25 PM, Erin Noe-Payne
> > > <er...@gmail.com>wrote:
> > >
> > >> On Wed, Mar 27, 2013 at 2:58 PM, Chris Geer <ch...@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
> > >> > > >> > <er...@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
Re: CXF Rest + WS Data Model
Posted by Erin Noe-Payne <er...@gmail.com>.
On Wed, Mar 27, 2013 at 4:12 PM, Matt Franklin <m....@gmail.com>wrote:
> On Wed, Mar 27, 2013 at 3:35 PM, Chris Geer <ch...@cxtsoftware.com> wrote:
> > On Wed, Mar 27, 2013 at 12:25 PM, Erin Noe-Payne
> > <er...@gmail.com>wrote:
> >
> >> On Wed, Mar 27, 2013 at 2:58 PM, Chris Geer <ch...@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 <ch...@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
> >> > > >> > <er...@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
>
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.
> 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.
>
> >
> > 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?
> >> > > >> >> >
> >> > > >> >>
> >> > > >>
> >> > >
> >> >
> >>
>
Re: CXF Rest + WS Data Model
Posted by Matt Franklin <m....@gmail.com>.
On Wed, Mar 27, 2013 at 3:35 PM, Chris Geer <ch...@cxtsoftware.com> wrote:
> On Wed, Mar 27, 2013 at 12:25 PM, Erin Noe-Payne
> <er...@gmail.com>wrote:
>
>> On Wed, Mar 27, 2013 at 2:58 PM, Chris Geer <ch...@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 <ch...@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 <ch...@cxtsoftware.com>
>> > > wrote:
>> > > >> > On Wed, Mar 27, 2013 at 10:42 AM, Erin Noe-Payne
>> > > >> > <er...@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?
>> > > >> >> >
>> > > >> >>
>> > > >>
>> > >
>> >
>>
Re: CXF Rest + WS Data Model
Posted by Chris Geer <ch...@cxtsoftware.com>.
On Wed, Mar 27, 2013 at 12:25 PM, Erin Noe-Payne
<er...@gmail.com>wrote:
> On Wed, Mar 27, 2013 at 2:58 PM, Chris Geer <ch...@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 <ch...@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 <ch...@cxtsoftware.com>
> > > wrote:
> > > >> > On Wed, Mar 27, 2013 at 10:42 AM, Erin Noe-Payne
> > > >> > <er...@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
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?
> > > >> >> >
> > > >> >>
> > > >>
> > >
> >
>
Re: CXF Rest + WS Data Model
Posted by Erin Noe-Payne <er...@gmail.com>.
On Wed, Mar 27, 2013 at 2:58 PM, Chris Geer <ch...@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 <ch...@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 <ch...@cxtsoftware.com>
> > wrote:
> > >> > On Wed, Mar 27, 2013 at 10:42 AM, Erin Noe-Payne
> > >> > <er...@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?
> > >> >> >
> > >> >>
> > >>
> >
>
Re: CXF Rest + WS Data Model
Posted by Chris Geer <ch...@cxtsoftware.com>.
On Wed, Mar 27, 2013 at 11:50 AM, Matt Franklin <m....@gmail.com>wrote:
> On Wed, Mar 27, 2013 at 2:32 PM, Chris Geer <ch...@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 <ch...@cxtsoftware.com>
> wrote:
> >> > On Wed, Mar 27, 2013 at 10:42 AM, Erin Noe-Payne
> >> > <er...@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?
> >> >> >
> >> >>
> >>
>
Re: CXF Rest + WS Data Model
Posted by Matt Franklin <m....@gmail.com>.
On Wed, Mar 27, 2013 at 2:32 PM, Chris Geer <ch...@cxtsoftware.com> wrote:
> On Wed, Mar 27, 2013 at 11:27 AM, Matt Franklin <m....@gmail.com>wrote:
>
>> On Wed, Mar 27, 2013 at 1:59 PM, Chris Geer <ch...@cxtsoftware.com> wrote:
>> > On Wed, Mar 27, 2013 at 10:42 AM, Erin Noe-Payne
>> > <er...@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 <ch...@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.
>
>>
>> >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?
>> >> >
>> >>
>>
Re: CXF Rest + WS Data Model
Posted by Chris Geer <ch...@cxtsoftware.com>.
On Wed, Mar 27, 2013 at 11:27 AM, Matt Franklin <m....@gmail.com>wrote:
> On Wed, Mar 27, 2013 at 1:59 PM, Chris Geer <ch...@cxtsoftware.com> wrote:
> > On Wed, Mar 27, 2013 at 10:42 AM, Erin Noe-Payne
> > <er...@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 <ch...@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.
>
> >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?
> >> >
> >>
>
Re: CXF Rest + WS Data Model
Posted by Matt Franklin <m....@gmail.com>.
On Wed, Mar 27, 2013 at 1:59 PM, Chris Geer <ch...@cxtsoftware.com> wrote:
> On Wed, Mar 27, 2013 at 10:42 AM, Erin Noe-Payne
> <er...@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 <ch...@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.
>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.
>
>>
>>
>> >
>> > 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?
>> >
>>
Re: CXF Rest + WS Data Model
Posted by Chris Geer <ch...@cxtsoftware.com>.
On Wed, Mar 27, 2013 at 10:42 AM, Erin Noe-Payne
<er...@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 <ch...@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). Maybe it makes more sense to have a different web
service for rendering by each provider??? Otherwise this "core" service has
to know about all the different providers which can be a problem moving
forward.
>
>
> >
> > 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?
> >
>
Re: CXF Rest + WS Data Model
Posted by Erin Noe-Payne <er...@gmail.com>.
On Wed, Mar 27, 2013 at 1:16 PM, Matt Franklin <m....@gmail.com>wrote:
> On Thu, Mar 21, 2013 at 5:32 PM, Chris Geer <ch...@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.
>
> 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...
>
> 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?
>
Re: CXF Rest + WS Data Model
Posted by Matt Franklin <m....@gmail.com>.
On Thu, Mar 21, 2013 at 5:32 PM, Chris Geer <ch...@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?
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
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?
Thoughts?
Re: CXF Rest + WS Data Model
Posted by Chris Geer <ch...@cxtsoftware.com>.
On Tue, Mar 26, 2013 at 7:27 AM, Matt Franklin <m....@gmail.com>wrote:
> On Fri, Mar 22, 2013 at 12:13 PM, Chris Geer <ch...@cxtsoftware.com>
> wrote:
> > On Fri, Mar 22, 2013 at 5:42 AM, Matt Franklin <m.ben.franklin@gmail.com
> >wrote:
> >
> >> On Thursday, March 21, 2013, Chris Geer wrote:
> >>
> >> > On Thu, Mar 21, 2013 at 4:32 PM, Matt Franklin <
> m.ben.franklin@gmail.com
> >> <javascript:;>
> >> > >wrote:
> >> >
> >> > > On Thu, Mar 21, 2013 at 5:32 PM, Chris Geer <chris@cxtsoftware.com
> >> <javascript:;>>
> >> > wrote:
> >> > > > I've done a first cut at adding some new CXF based REST web
> services
> >> > > which
> >> > > > use a different data model and uploaded a patch to the ticket
> [1]. I
> >> > > tried
> >> > > > to upload to Review Board but it was too big I think. The biggest
> >> > change
> >> > > is
> >> > > > I had to relocate all the model interfaces from
> >> > > > rave-core/org.apache.rave.portal.model ->
> >> > > > rave-core-api/org.apache.rave.model. We would have to had do
> >> > > > it eventually but I needed to do it now to build the conversions
> >> > between
> >> > > > the models. One nice thing is that the web services support
> partial
> >> > data
> >> > > > objects so we can limit fields on retrieval for security reasons
> and
> >> we
> >> > > can
> >> > > > accept partial updates.
> >> > > >
> >> > > > At this point I'd like to commit this small step because I don't
> want
> >> > to
> >> > > > get into a situation where the model is being changes in trunk in
> the
> >> > old
> >> > > > location and by me in the new location which will cause major
> merge
> >> > > issues.
> >> > > > If there are any objections I can move all these changes to a
> branch
> >> > and
> >> > > we
> >> > > > can deal with the merge issues later.
> >> > >
> >> > > IMO, it would be better to make some of these changes incrementally
> >> > > and without review. Specifically, refactoring and package structure
> >> > > changes are too big to commit as one single patch.
> >> > >
> >> >
> >> > Incrementally is the challenge since things are so intertwined. I
> don't
> >> > mind doing it without review, just more of a heads up that all the
> model
> >> > interfaces are moving to a new module/package.
> >>
> >>
> >> +1 for the move
> >>
> >
> > Change is checked in. I've tested to the best of my ability but please
> let
> > me know if you find issues and I'll fix them.
>
> Is there an issue in JIRA where we can attach sub-issues for
> re-creating various API pieces in the CXF layer? I looked but didn't
> see one and I would like to help move the Page API over.
>
Could use RAVE-910.
>
> >
> >>
> >>
> >> >
> >> > >
> >> > > >
> >> > > > Chris
> >> > > >
> >> > > > [1] https://issues.apache.org/jira/browse/RAVE-910
> >> > >
> >> >
> >>
>
Re: CXF Rest + WS Data Model
Posted by Matt Franklin <m....@gmail.com>.
On Fri, Mar 22, 2013 at 12:13 PM, Chris Geer <ch...@cxtsoftware.com> wrote:
> On Fri, Mar 22, 2013 at 5:42 AM, Matt Franklin <m....@gmail.com>wrote:
>
>> On Thursday, March 21, 2013, Chris Geer wrote:
>>
>> > On Thu, Mar 21, 2013 at 4:32 PM, Matt Franklin <m.ben.franklin@gmail.com
>> <javascript:;>
>> > >wrote:
>> >
>> > > On Thu, Mar 21, 2013 at 5:32 PM, Chris Geer <chris@cxtsoftware.com
>> <javascript:;>>
>> > wrote:
>> > > > I've done a first cut at adding some new CXF based REST web services
>> > > which
>> > > > use a different data model and uploaded a patch to the ticket [1]. I
>> > > tried
>> > > > to upload to Review Board but it was too big I think. The biggest
>> > change
>> > > is
>> > > > I had to relocate all the model interfaces from
>> > > > rave-core/org.apache.rave.portal.model ->
>> > > > rave-core-api/org.apache.rave.model. We would have to had do
>> > > > it eventually but I needed to do it now to build the conversions
>> > between
>> > > > the models. One nice thing is that the web services support partial
>> > data
>> > > > objects so we can limit fields on retrieval for security reasons and
>> we
>> > > can
>> > > > accept partial updates.
>> > > >
>> > > > At this point I'd like to commit this small step because I don't want
>> > to
>> > > > get into a situation where the model is being changes in trunk in the
>> > old
>> > > > location and by me in the new location which will cause major merge
>> > > issues.
>> > > > If there are any objections I can move all these changes to a branch
>> > and
>> > > we
>> > > > can deal with the merge issues later.
>> > >
>> > > IMO, it would be better to make some of these changes incrementally
>> > > and without review. Specifically, refactoring and package structure
>> > > changes are too big to commit as one single patch.
>> > >
>> >
>> > Incrementally is the challenge since things are so intertwined. I don't
>> > mind doing it without review, just more of a heads up that all the model
>> > interfaces are moving to a new module/package.
>>
>>
>> +1 for the move
>>
>
> Change is checked in. I've tested to the best of my ability but please let
> me know if you find issues and I'll fix them.
Is there an issue in JIRA where we can attach sub-issues for
re-creating various API pieces in the CXF layer? I looked but didn't
see one and I would like to help move the Page API over.
>
>>
>>
>> >
>> > >
>> > > >
>> > > > Chris
>> > > >
>> > > > [1] https://issues.apache.org/jira/browse/RAVE-910
>> > >
>> >
>>
Re: CXF Rest + WS Data Model
Posted by Jasha Joachimsthal <ja...@apache.org>.
On 22 March 2013 21:37, Chris Geer <ch...@cxtsoftware.com> wrote:
> On Fri, Mar 22, 2013 at 12:59 PM, Chris Geer <ch...@cxtsoftware.com>
> wrote:
>
> > On Fri, Mar 22, 2013 at 12:12 PM, Jasha Joachimsthal <jasha@apache.org
> >wrote:
> >
> >> On 22 March 2013 17:13, Chris Geer <ch...@cxtsoftware.com> wrote:
> >>
> >> > On Fri, Mar 22, 2013 at 5:42 AM, Matt Franklin <
> >> m.ben.franklin@gmail.com
> >> > >wrote:
> >> >
> >> > > On Thursday, March 21, 2013, Chris Geer wrote:
> >> > >
> >> > > > On Thu, Mar 21, 2013 at 4:32 PM, Matt Franklin <
> >> > m.ben.franklin@gmail.com
> >> > > <javascript:;>
> >> > > > >wrote:
> >> > > >
> >> > > > > On Thu, Mar 21, 2013 at 5:32 PM, Chris Geer <
> >> chris@cxtsoftware.com
> >> > > <javascript:;>>
> >> > > > wrote:
> >> > > > > > I've done a first cut at adding some new CXF based REST web
> >> > services
> >> > > > > which
> >> > > > > > use a different data model and uploaded a patch to the ticket
> >> [1].
> >> > I
> >> > > > > tried
> >> > > > > > to upload to Review Board but it was too big I think. The
> >> biggest
> >> > > > change
> >> > > > > is
> >> > > > > > I had to relocate all the model interfaces from
> >> > > > > > rave-core/org.apache.rave.portal.model ->
> >> > > > > > rave-core-api/org.apache.rave.model. We would have to had do
> >> > > > > > it eventually but I needed to do it now to build the
> conversions
> >> > > > between
> >> > > > > > the models. One nice thing is that the web services support
> >> partial
> >> > > > data
> >> > > > > > objects so we can limit fields on retrieval for security
> reasons
> >> > and
> >> > > we
> >> > > > > can
> >> > > > > > accept partial updates.
> >> > > > > >
> >> > > > > > At this point I'd like to commit this small step because I
> don't
> >> > want
> >> > > > to
> >> > > > > > get into a situation where the model is being changes in trunk
> >> in
> >> > the
> >> > > > old
> >> > > > > > location and by me in the new location which will cause major
> >> merge
> >> > > > > issues.
> >> > > > > > If there are any objections I can move all these changes to a
> >> > branch
> >> > > > and
> >> > > > > we
> >> > > > > > can deal with the merge issues later.
> >> > > > >
> >> > > > > IMO, it would be better to make some of these changes
> >> incrementally
> >> > > > > and without review. Specifically, refactoring and package
> >> structure
> >> > > > > changes are too big to commit as one single patch.
> >> > > > >
> >> > > >
> >> > > > Incrementally is the challenge since things are so intertwined. I
> >> don't
> >> > > > mind doing it without review, just more of a heads up that all the
> >> > model
> >> > > > interfaces are moving to a new module/package.
> >> > >
> >> > >
> >> > > +1 for the move
> >> > >
> >> >
> >> > Change is checked in. I've tested to the best of my ability but please
> >> let
> >> > me know if you find issues and I'll fix them.
> >> >
> >>
> >> Great work!
> >>
> >> When I started the portal I saw the following warning
> >> [INFO] [talledLocalContainer] INFO:
> >>
> >>
> validateJarFile(~/rave-project/rave-portal/target/tomcat6x/webapps/portal/WEB-INF/lib/geronimo-servlet_3.0_spec-1.0.jar)
> >> - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class:
> >> javax/servlet/Servlet.class
> >>
> >> Apparently the org.apache.cxf:cxf-bundle-jaxrs includes following
> >> (unwanted) dependencies:
> >>
> >> [INFO] | +- org.eclipse.jetty:jetty-server:jar:8.1.7.v20120910:compile
> >> [INFO] | +-
> >> org.eclipse.jetty:jetty-continuation:jar:8.1.7.v20120910:compile
> >> [INFO] | +- org.eclipse.jetty:jetty-http:jar:8.1.7.v20120910:compile
> >> [INFO] | +- org.eclipse.jetty:jetty-io:jar:8.1.7.v20120910:compile
> >> [INFO] | +- org.eclipse.jetty:jetty-util:jar:8.1.7.v20120910:compile
> >> [INFO] | +-
> org.eclipse.jetty:jetty-security:jar:8.1.7.v20120910:compile
> >> [INFO] | +-
> >> org.apache.geronimo.specs:geronimo-servlet_3.0_spec:jar:1.0:compile
> >>
> >> Is there an alternative cxf jar that offers the same functionality but
> >> without the jetty and servlet jar?
> >>
> >
> > Yes, good catch. I'll see what I can do.
> >
>
> I just checked in some changes which seems to fix that issue. I didn't see
> the warning any longer but let me know if it's still there.
>
They're gone now :)
>
> Chris
>
> >
> >> Jasha
> >>
> >>
> >>
> >>
> >> >
> >> > >
> >> > >
> >> > > >
> >> > > > >
> >> > > > > >
> >> > > > > > Chris
> >> > > > > >
> >> > > > > > [1] https://issues.apache.org/jira/browse/RAVE-910
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
Re: CXF Rest + WS Data Model
Posted by Chris Geer <ch...@cxtsoftware.com>.
On Fri, Mar 22, 2013 at 12:59 PM, Chris Geer <ch...@cxtsoftware.com> wrote:
> On Fri, Mar 22, 2013 at 12:12 PM, Jasha Joachimsthal <ja...@apache.org>wrote:
>
>> On 22 March 2013 17:13, Chris Geer <ch...@cxtsoftware.com> wrote:
>>
>> > On Fri, Mar 22, 2013 at 5:42 AM, Matt Franklin <
>> m.ben.franklin@gmail.com
>> > >wrote:
>> >
>> > > On Thursday, March 21, 2013, Chris Geer wrote:
>> > >
>> > > > On Thu, Mar 21, 2013 at 4:32 PM, Matt Franklin <
>> > m.ben.franklin@gmail.com
>> > > <javascript:;>
>> > > > >wrote:
>> > > >
>> > > > > On Thu, Mar 21, 2013 at 5:32 PM, Chris Geer <
>> chris@cxtsoftware.com
>> > > <javascript:;>>
>> > > > wrote:
>> > > > > > I've done a first cut at adding some new CXF based REST web
>> > services
>> > > > > which
>> > > > > > use a different data model and uploaded a patch to the ticket
>> [1].
>> > I
>> > > > > tried
>> > > > > > to upload to Review Board but it was too big I think. The
>> biggest
>> > > > change
>> > > > > is
>> > > > > > I had to relocate all the model interfaces from
>> > > > > > rave-core/org.apache.rave.portal.model ->
>> > > > > > rave-core-api/org.apache.rave.model. We would have to had do
>> > > > > > it eventually but I needed to do it now to build the conversions
>> > > > between
>> > > > > > the models. One nice thing is that the web services support
>> partial
>> > > > data
>> > > > > > objects so we can limit fields on retrieval for security reasons
>> > and
>> > > we
>> > > > > can
>> > > > > > accept partial updates.
>> > > > > >
>> > > > > > At this point I'd like to commit this small step because I don't
>> > want
>> > > > to
>> > > > > > get into a situation where the model is being changes in trunk
>> in
>> > the
>> > > > old
>> > > > > > location and by me in the new location which will cause major
>> merge
>> > > > > issues.
>> > > > > > If there are any objections I can move all these changes to a
>> > branch
>> > > > and
>> > > > > we
>> > > > > > can deal with the merge issues later.
>> > > > >
>> > > > > IMO, it would be better to make some of these changes
>> incrementally
>> > > > > and without review. Specifically, refactoring and package
>> structure
>> > > > > changes are too big to commit as one single patch.
>> > > > >
>> > > >
>> > > > Incrementally is the challenge since things are so intertwined. I
>> don't
>> > > > mind doing it without review, just more of a heads up that all the
>> > model
>> > > > interfaces are moving to a new module/package.
>> > >
>> > >
>> > > +1 for the move
>> > >
>> >
>> > Change is checked in. I've tested to the best of my ability but please
>> let
>> > me know if you find issues and I'll fix them.
>> >
>>
>> Great work!
>>
>> When I started the portal I saw the following warning
>> [INFO] [talledLocalContainer] INFO:
>>
>> validateJarFile(~/rave-project/rave-portal/target/tomcat6x/webapps/portal/WEB-INF/lib/geronimo-servlet_3.0_spec-1.0.jar)
>> - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class:
>> javax/servlet/Servlet.class
>>
>> Apparently the org.apache.cxf:cxf-bundle-jaxrs includes following
>> (unwanted) dependencies:
>>
>> [INFO] | +- org.eclipse.jetty:jetty-server:jar:8.1.7.v20120910:compile
>> [INFO] | +-
>> org.eclipse.jetty:jetty-continuation:jar:8.1.7.v20120910:compile
>> [INFO] | +- org.eclipse.jetty:jetty-http:jar:8.1.7.v20120910:compile
>> [INFO] | +- org.eclipse.jetty:jetty-io:jar:8.1.7.v20120910:compile
>> [INFO] | +- org.eclipse.jetty:jetty-util:jar:8.1.7.v20120910:compile
>> [INFO] | +- org.eclipse.jetty:jetty-security:jar:8.1.7.v20120910:compile
>> [INFO] | +-
>> org.apache.geronimo.specs:geronimo-servlet_3.0_spec:jar:1.0:compile
>>
>> Is there an alternative cxf jar that offers the same functionality but
>> without the jetty and servlet jar?
>>
>
> Yes, good catch. I'll see what I can do.
>
I just checked in some changes which seems to fix that issue. I didn't see
the warning any longer but let me know if it's still there.
Chris
>
>> Jasha
>>
>>
>>
>>
>> >
>> > >
>> > >
>> > > >
>> > > > >
>> > > > > >
>> > > > > > Chris
>> > > > > >
>> > > > > > [1] https://issues.apache.org/jira/browse/RAVE-910
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: CXF Rest + WS Data Model
Posted by Chris Geer <ch...@cxtsoftware.com>.
On Fri, Mar 22, 2013 at 12:12 PM, Jasha Joachimsthal <ja...@apache.org>wrote:
> On 22 March 2013 17:13, Chris Geer <ch...@cxtsoftware.com> wrote:
>
> > On Fri, Mar 22, 2013 at 5:42 AM, Matt Franklin <m.ben.franklin@gmail.com
> > >wrote:
> >
> > > On Thursday, March 21, 2013, Chris Geer wrote:
> > >
> > > > On Thu, Mar 21, 2013 at 4:32 PM, Matt Franklin <
> > m.ben.franklin@gmail.com
> > > <javascript:;>
> > > > >wrote:
> > > >
> > > > > On Thu, Mar 21, 2013 at 5:32 PM, Chris Geer <chris@cxtsoftware.com
> > > <javascript:;>>
> > > > wrote:
> > > > > > I've done a first cut at adding some new CXF based REST web
> > services
> > > > > which
> > > > > > use a different data model and uploaded a patch to the ticket
> [1].
> > I
> > > > > tried
> > > > > > to upload to Review Board but it was too big I think. The biggest
> > > > change
> > > > > is
> > > > > > I had to relocate all the model interfaces from
> > > > > > rave-core/org.apache.rave.portal.model ->
> > > > > > rave-core-api/org.apache.rave.model. We would have to had do
> > > > > > it eventually but I needed to do it now to build the conversions
> > > > between
> > > > > > the models. One nice thing is that the web services support
> partial
> > > > data
> > > > > > objects so we can limit fields on retrieval for security reasons
> > and
> > > we
> > > > > can
> > > > > > accept partial updates.
> > > > > >
> > > > > > At this point I'd like to commit this small step because I don't
> > want
> > > > to
> > > > > > get into a situation where the model is being changes in trunk in
> > the
> > > > old
> > > > > > location and by me in the new location which will cause major
> merge
> > > > > issues.
> > > > > > If there are any objections I can move all these changes to a
> > branch
> > > > and
> > > > > we
> > > > > > can deal with the merge issues later.
> > > > >
> > > > > IMO, it would be better to make some of these changes incrementally
> > > > > and without review. Specifically, refactoring and package structure
> > > > > changes are too big to commit as one single patch.
> > > > >
> > > >
> > > > Incrementally is the challenge since things are so intertwined. I
> don't
> > > > mind doing it without review, just more of a heads up that all the
> > model
> > > > interfaces are moving to a new module/package.
> > >
> > >
> > > +1 for the move
> > >
> >
> > Change is checked in. I've tested to the best of my ability but please
> let
> > me know if you find issues and I'll fix them.
> >
>
> Great work!
>
> When I started the portal I saw the following warning
> [INFO] [talledLocalContainer] INFO:
>
> validateJarFile(~/rave-project/rave-portal/target/tomcat6x/webapps/portal/WEB-INF/lib/geronimo-servlet_3.0_spec-1.0.jar)
> - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class:
> javax/servlet/Servlet.class
>
> Apparently the org.apache.cxf:cxf-bundle-jaxrs includes following
> (unwanted) dependencies:
>
> [INFO] | +- org.eclipse.jetty:jetty-server:jar:8.1.7.v20120910:compile
> [INFO] | +-
> org.eclipse.jetty:jetty-continuation:jar:8.1.7.v20120910:compile
> [INFO] | +- org.eclipse.jetty:jetty-http:jar:8.1.7.v20120910:compile
> [INFO] | +- org.eclipse.jetty:jetty-io:jar:8.1.7.v20120910:compile
> [INFO] | +- org.eclipse.jetty:jetty-util:jar:8.1.7.v20120910:compile
> [INFO] | +- org.eclipse.jetty:jetty-security:jar:8.1.7.v20120910:compile
> [INFO] | +-
> org.apache.geronimo.specs:geronimo-servlet_3.0_spec:jar:1.0:compile
>
> Is there an alternative cxf jar that offers the same functionality but
> without the jetty and servlet jar?
>
Yes, good catch. I'll see what I can do.
>
> Jasha
>
>
>
>
> >
> > >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > Chris
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/RAVE-910
> > > > >
> > > >
> > >
> >
>
Re: CXF Rest + WS Data Model
Posted by Jasha Joachimsthal <ja...@apache.org>.
On 22 March 2013 17:13, Chris Geer <ch...@cxtsoftware.com> wrote:
> On Fri, Mar 22, 2013 at 5:42 AM, Matt Franklin <m.ben.franklin@gmail.com
> >wrote:
>
> > On Thursday, March 21, 2013, Chris Geer wrote:
> >
> > > On Thu, Mar 21, 2013 at 4:32 PM, Matt Franklin <
> m.ben.franklin@gmail.com
> > <javascript:;>
> > > >wrote:
> > >
> > > > On Thu, Mar 21, 2013 at 5:32 PM, Chris Geer <chris@cxtsoftware.com
> > <javascript:;>>
> > > wrote:
> > > > > I've done a first cut at adding some new CXF based REST web
> services
> > > > which
> > > > > use a different data model and uploaded a patch to the ticket [1].
> I
> > > > tried
> > > > > to upload to Review Board but it was too big I think. The biggest
> > > change
> > > > is
> > > > > I had to relocate all the model interfaces from
> > > > > rave-core/org.apache.rave.portal.model ->
> > > > > rave-core-api/org.apache.rave.model. We would have to had do
> > > > > it eventually but I needed to do it now to build the conversions
> > > between
> > > > > the models. One nice thing is that the web services support partial
> > > data
> > > > > objects so we can limit fields on retrieval for security reasons
> and
> > we
> > > > can
> > > > > accept partial updates.
> > > > >
> > > > > At this point I'd like to commit this small step because I don't
> want
> > > to
> > > > > get into a situation where the model is being changes in trunk in
> the
> > > old
> > > > > location and by me in the new location which will cause major merge
> > > > issues.
> > > > > If there are any objections I can move all these changes to a
> branch
> > > and
> > > > we
> > > > > can deal with the merge issues later.
> > > >
> > > > IMO, it would be better to make some of these changes incrementally
> > > > and without review. Specifically, refactoring and package structure
> > > > changes are too big to commit as one single patch.
> > > >
> > >
> > > Incrementally is the challenge since things are so intertwined. I don't
> > > mind doing it without review, just more of a heads up that all the
> model
> > > interfaces are moving to a new module/package.
> >
> >
> > +1 for the move
> >
>
> Change is checked in. I've tested to the best of my ability but please let
> me know if you find issues and I'll fix them.
>
Great work!
When I started the portal I saw the following warning
[INFO] [talledLocalContainer] INFO:
validateJarFile(~/rave-project/rave-portal/target/tomcat6x/webapps/portal/WEB-INF/lib/geronimo-servlet_3.0_spec-1.0.jar)
- jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class:
javax/servlet/Servlet.class
Apparently the org.apache.cxf:cxf-bundle-jaxrs includes following
(unwanted) dependencies:
[INFO] | +- org.eclipse.jetty:jetty-server:jar:8.1.7.v20120910:compile
[INFO] | +-
org.eclipse.jetty:jetty-continuation:jar:8.1.7.v20120910:compile
[INFO] | +- org.eclipse.jetty:jetty-http:jar:8.1.7.v20120910:compile
[INFO] | +- org.eclipse.jetty:jetty-io:jar:8.1.7.v20120910:compile
[INFO] | +- org.eclipse.jetty:jetty-util:jar:8.1.7.v20120910:compile
[INFO] | +- org.eclipse.jetty:jetty-security:jar:8.1.7.v20120910:compile
[INFO] | +-
org.apache.geronimo.specs:geronimo-servlet_3.0_spec:jar:1.0:compile
Is there an alternative cxf jar that offers the same functionality but
without the jetty and servlet jar?
Jasha
>
> >
> >
> > >
> > > >
> > > > >
> > > > > Chris
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/RAVE-910
> > > >
> > >
> >
>
Re: CXF Rest + WS Data Model
Posted by Chris Geer <ch...@cxtsoftware.com>.
On Fri, Mar 22, 2013 at 5:42 AM, Matt Franklin <m....@gmail.com>wrote:
> On Thursday, March 21, 2013, Chris Geer wrote:
>
> > On Thu, Mar 21, 2013 at 4:32 PM, Matt Franklin <m.ben.franklin@gmail.com
> <javascript:;>
> > >wrote:
> >
> > > On Thu, Mar 21, 2013 at 5:32 PM, Chris Geer <chris@cxtsoftware.com
> <javascript:;>>
> > wrote:
> > > > I've done a first cut at adding some new CXF based REST web services
> > > which
> > > > use a different data model and uploaded a patch to the ticket [1]. I
> > > tried
> > > > to upload to Review Board but it was too big I think. The biggest
> > change
> > > is
> > > > I had to relocate all the model interfaces from
> > > > rave-core/org.apache.rave.portal.model ->
> > > > rave-core-api/org.apache.rave.model. We would have to had do
> > > > it eventually but I needed to do it now to build the conversions
> > between
> > > > the models. One nice thing is that the web services support partial
> > data
> > > > objects so we can limit fields on retrieval for security reasons and
> we
> > > can
> > > > accept partial updates.
> > > >
> > > > At this point I'd like to commit this small step because I don't want
> > to
> > > > get into a situation where the model is being changes in trunk in the
> > old
> > > > location and by me in the new location which will cause major merge
> > > issues.
> > > > If there are any objections I can move all these changes to a branch
> > and
> > > we
> > > > can deal with the merge issues later.
> > >
> > > IMO, it would be better to make some of these changes incrementally
> > > and without review. Specifically, refactoring and package structure
> > > changes are too big to commit as one single patch.
> > >
> >
> > Incrementally is the challenge since things are so intertwined. I don't
> > mind doing it without review, just more of a heads up that all the model
> > interfaces are moving to a new module/package.
>
>
> +1 for the move
>
Change is checked in. I've tested to the best of my ability but please let
me know if you find issues and I'll fix them.
>
>
> >
> > >
> > > >
> > > > Chris
> > > >
> > > > [1] https://issues.apache.org/jira/browse/RAVE-910
> > >
> >
>
Re: CXF Rest + WS Data Model
Posted by Matt Franklin <m....@gmail.com>.
On Thursday, March 21, 2013, Chris Geer wrote:
> On Thu, Mar 21, 2013 at 4:32 PM, Matt Franklin <m.ben.franklin@gmail.com<javascript:;>
> >wrote:
>
> > On Thu, Mar 21, 2013 at 5:32 PM, Chris Geer <chris@cxtsoftware.com<javascript:;>>
> wrote:
> > > I've done a first cut at adding some new CXF based REST web services
> > which
> > > use a different data model and uploaded a patch to the ticket [1]. I
> > tried
> > > to upload to Review Board but it was too big I think. The biggest
> change
> > is
> > > I had to relocate all the model interfaces from
> > > rave-core/org.apache.rave.portal.model ->
> > > rave-core-api/org.apache.rave.model. We would have to had do
> > > it eventually but I needed to do it now to build the conversions
> between
> > > the models. One nice thing is that the web services support partial
> data
> > > objects so we can limit fields on retrieval for security reasons and we
> > can
> > > accept partial updates.
> > >
> > > At this point I'd like to commit this small step because I don't want
> to
> > > get into a situation where the model is being changes in trunk in the
> old
> > > location and by me in the new location which will cause major merge
> > issues.
> > > If there are any objections I can move all these changes to a branch
> and
> > we
> > > can deal with the merge issues later.
> >
> > IMO, it would be better to make some of these changes incrementally
> > and without review. Specifically, refactoring and package structure
> > changes are too big to commit as one single patch.
> >
>
> Incrementally is the challenge since things are so intertwined. I don't
> mind doing it without review, just more of a heads up that all the model
> interfaces are moving to a new module/package.
+1 for the move
>
> >
> > >
> > > Chris
> > >
> > > [1] https://issues.apache.org/jira/browse/RAVE-910
> >
>
Re: CXF Rest + WS Data Model
Posted by Chris Geer <ch...@cxtsoftware.com>.
On Thu, Mar 21, 2013 at 4:32 PM, Matt Franklin <m....@gmail.com>wrote:
> On Thu, Mar 21, 2013 at 5:32 PM, Chris Geer <ch...@cxtsoftware.com> wrote:
> > I've done a first cut at adding some new CXF based REST web services
> which
> > use a different data model and uploaded a patch to the ticket [1]. I
> tried
> > to upload to Review Board but it was too big I think. The biggest change
> is
> > I had to relocate all the model interfaces from
> > rave-core/org.apache.rave.portal.model ->
> > rave-core-api/org.apache.rave.model. We would have to had do
> > it eventually but I needed to do it now to build the conversions between
> > the models. One nice thing is that the web services support partial data
> > objects so we can limit fields on retrieval for security reasons and we
> can
> > accept partial updates.
> >
> > At this point I'd like to commit this small step because I don't want to
> > get into a situation where the model is being changes in trunk in the old
> > location and by me in the new location which will cause major merge
> issues.
> > If there are any objections I can move all these changes to a branch and
> we
> > can deal with the merge issues later.
>
> IMO, it would be better to make some of these changes incrementally
> and without review. Specifically, refactoring and package structure
> changes are too big to commit as one single patch.
>
Incrementally is the challenge since things are so intertwined. I don't
mind doing it without review, just more of a heads up that all the model
interfaces are moving to a new module/package.
>
> >
> > Chris
> >
> > [1] https://issues.apache.org/jira/browse/RAVE-910
>
Re: CXF Rest + WS Data Model
Posted by Matt Franklin <m....@gmail.com>.
On Thu, Mar 21, 2013 at 5:32 PM, Chris Geer <ch...@cxtsoftware.com> wrote:
> I've done a first cut at adding some new CXF based REST web services which
> use a different data model and uploaded a patch to the ticket [1]. I tried
> to upload to Review Board but it was too big I think. The biggest change is
> I had to relocate all the model interfaces from
> rave-core/org.apache.rave.portal.model ->
> rave-core-api/org.apache.rave.model. We would have to had do
> it eventually but I needed to do it now to build the conversions between
> the models. One nice thing is that the web services support partial data
> objects so we can limit fields on retrieval for security reasons and we can
> accept partial updates.
>
> At this point I'd like to commit this small step because I don't want to
> get into a situation where the model is being changes in trunk in the old
> location and by me in the new location which will cause major merge issues.
> If there are any objections I can move all these changes to a branch and we
> can deal with the merge issues later.
IMO, it would be better to make some of these changes incrementally
and without review. Specifically, refactoring and package structure
changes are too big to commit as one single patch.
>
> Chris
>
> [1] https://issues.apache.org/jira/browse/RAVE-910