rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Franklin <m.ben.frank...@gmail.com>
Subject Re: CXF Rest + WS Data Model
Date Thu, 28 Mar 2013 16:06:28 GMT
On Thu, Mar 28, 2013 at 11:57 AM, Chris Geer <chris@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 <chris@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
>> >> > <erin.noe.payne@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
>> >> >>> > > > <erin.noe.payne@gmail.com>wrote:
>> >> >>> > > >
>> >> >>> > > >> On Wed, Mar 27, 2013 at 2:58 PM, Chris Geer
<
>> >> chris@cxtsoftware.com>
>> >> >>> > > wrote:
>> >> >>> > > >>
>> >> >>> > > >> > On Wed, Mar 27, 2013 at 11:50 AM, Matt
Franklin <
>> >> >>> > > >> m.ben.franklin@gmail.com
>> >> >>> > > >> > >wrote:
>> >> >>> > > >> >
>> >> >>> > > >> > > On Wed, Mar 27, 2013 at 2:32 PM,
Chris Geer <
>> >> >>> > chris@cxtsoftware.com>
>> >> >>> > > >> > wrote:
>> >> >>> > > >> > > > On Wed, Mar 27, 2013 at 11:27
AM, Matt Franklin <
>> >> >>> > > >> > > m.ben.franklin@gmail.com>wrote:
>> >> >>> > > >> > > >
>> >> >>> > > >> > > >> On Wed, Mar 27, 2013
at 1:59 PM, Chris Geer <
>> >> >>> > > chris@cxtsoftware.com>
>> >> >>> > > >> > > wrote:
>> >> >>> > > >> > > >> > On Wed, Mar 27,
2013 at 10:42 AM, Erin Noe-Payne
>> >> >>> > > >> > > >> > <erin.noe.payne@gmail.com>wrote:
>> >> >>> > > >> > > >> >
>> >> >>> > > >> > > >> >> On Wed, Mar
27, 2013 at 1:16 PM, Matt Franklin <
>> >> >>> > > >> > > >> m.ben.franklin@gmail.com
>> >> >>> > > >> > > >> >> >wrote:
>> >> >>> > > >> > > >> >>
>> >> >>> > > >> > > >> >> > On Thu,
Mar 21, 2013 at 5:32 PM, Chris Geer <
>> >> >>> > > >> > chris@cxtsoftware.com
>> >> >>> > > >> > > >
>> >> >>> > > >> > > >> >> wrote:
>> >> >>> > > >> > > >> >> > > I've
done a first cut at adding some new CXF
>> based
>> >> >>> REST
>> >> >>> > > web
>> >> >>> > > >> > > services
>> >> >>> > > >> > > >> >> > which
>> >> >>> > > >> > > >> >> > > use
a different data model
>> >> >>> > > >> > > >> >> >
>> >> >>> > > >> > > >> >> > As part
of RAVE-924, I have created a new page
>> >> model for
>> >> >>> > > web.
>> >> >>> > > >> >  As I
>> >> >>> > > >> > > >> >> > was building
it, it occurred to me that there
>> are a
>> >> >>> couple
>> >> >>> > > of
>> >> >>> > > >> > > >> >> > different
ways we will want/need to use the REST
>> >> >>> interface
>> >> >>> > > for
>> >> >>> > > >> > > Page:
>> >> >>> > > >> > > >> >> >
>> >> >>> > > >> > > >> >> > 1) As an
export mechanism
>> >> >>> > > >> > > >> >> > 2) As an
OMDL export mechanism
>> >> >>> > > >> > > >> >> > 3) As an
entry point for applications who want to
>> >> render
>> >> >>> > > >> widgets
>> >> >>> > > >> > > >> >> > (including
the portal)
>> >> >>> > > >> > > >> >> >
>> >> >>> > > >> > > >> >> > IMO, #1
is straight forward.  For number 2, I was
>> >> >>> thinking
>> >> >>> > > that
>> >> >>> > > >> > it
>> >> >>> > > >> > > >> >> > would be
better if there was an OMDL mime type so
>> >> the
>> >> >>> > > logical
>> >> >>> > > >> > > mapping
>> >> >>> > > >> > > >> >> > remains
the same (/api/pages/{id}) as in the
>> regular
>> >> >>> > export.
>> >> >>> > > >> >  What
>> >> >>> > > >> > > >> >> > does everyone
think about using
>> >> >>> application/vnd.omdl+xml?
>> >> >>> > > >> > > >> >> >
>> >> >>> > > >> > > >> >>
>> >> >>> > > >> > > >> >> +1 here, I think
mime type is the right approach. I
>> >> have
>> >> >>> no
>> >> >>> > > >> opinion
>> >> >>> > > >> > > on
>> >> >>> > > >> > > >> the
>> >> >>> > > >> > > >> >> actual label
of the mime type - that looks fine.
>> >> >>> > > >> > > >> >>
>> >> >>> > > >> > > >> >
>> >> >>> > > >> > > >> > +1
>> >> >>> > > >> > > >> >
>> >> >>> > > >> > > >> >>
>> >> >>> > > >I don't think pages are user-specific, they just
have a
>> >> relationship
>> >> >>> to
>> >> >>> > users. They are still a first class resource in rave and
should be
>> >> >>> > accessible independent of user, so /api/pages should remain
imo.
>> >> There's
>> >> >>> > nothing wrong with having multiple api routes to arrive
at the
>> same
>> >> >>> > resource.
>> >> >>> >
>> >> >>> >
>> >> >>> +1
>> >> >>>
>> >> >>>
>> >> >>> >
>> >> >>> > > We also need to consider how to get the pages by
context (IE
>> >> Portal,
>> >> >>> > > Profile, etc)
>> >> >>> >
>> >> >>> >
>> >> >>> > what do you mean by this? Filtering the data set by a
property?
>> >> Portal,
>> >> >>> > profile or whatever else are just a property of the page.
>> >> >>>
>> >> >>>
>> >> >>> Yes, but to build the portal, you will need to request all
pages
>> for a
>> >> user
>> >> >>> in the portal context.  In the profile, you will need to do
the
>> same in
>> >> >>> that context.  This extends to any context that developers
want to
>> >> support.
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >> 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
>> >> >>>
>> >>
>>

Mime
View raw message