rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Geer <ch...@cxtsoftware.com>
Subject Re: Rave Data Structures
Date Wed, 18 Sep 2013 19:29:49 GMT
Dan,

My proposal is that on the server side, we do not add the extra attributes
to the REST model. Instead we have the render endpoint that will return the
full object tree with the extra attributes. So on the server side there
would be a different object like you said i.e. RenderedRegionWidget. An
alternative is to not create an objet and just build the JSON directly for
the render endpoint.

I'm also ok with the server ignoring unknown attributes on a save/update.

Chris


On Wed, Sep 18, 2013 at 3:56 AM, Dan Gornstein <dan@gornstein.com> wrote:

> Chris,
>
> I think I was a bit confused before and might have been inaccurate in what
> I was trying to say. I have been thinking about it a bit more had a few
> more questions for you.
>
> The endpoint which returns information for rendering a page is a nested
> object and I agree should be read only, meaning you cannot post to the same
> endpoint with the nested data model to save your object. In the angular
> branch right now, when we hit this endpoint we break down the response into
> their individual angular resource objects (page, regions, regionWidgets)
> which point to the CRUD interfaces.
>
> The way the pages for render endpoint works right now is to use pageService
> to get the canonical model of a page and transform it into the REST model
> and send it through the DefaultRenderService to prepare the regionWidgets.
> This means it ends up returning the REST model of RegionWidgets in the
> pages for render endpoint. So if you wanted to add the pageId and title,
> they would have to be properties on the RegionWidget REST model. Are you
> proposing that we make this pages for render endpoint be compiled with
> different model objects other than the REST ones? Would there be something
> along the lines of RegionWidgetRender, which has the extra properties but
> does not have CRUD operations?
>
> If this was the case and we did not add pageId and title to the REST models
> of RegionWidgets, what will happen if we hit the pages for render endpoint
> and in angular still broke them down into their individual resource
> objects? Would you be allowed to save a RegionWidget to
> /pages/<page-id>/regions/<region-id>/regionwidgets/<region-widget-id>
which
> had title and pageId on it and the server would ignore it, or would you
> expect the server to throw an error?
>
> Thanks,
> Dan
>
>
>
> On Mon, Sep 16, 2013 at 1:21 PM, Michael Jett <mikesjett@gmail.com> wrote:
>
> > I'd like to pause this discussion for a brief moment, and advise that we
> > watch this APIGee video.
> > http://www.youtube.com/watch?feature=player_embedded&v=QpAhXa12xvU
> >
> > This is something that Erin pointed us to early on, and serves as a basis
> > for a good RESTful architecture. There are too many good points made that
> > will allow our API to scale and be intuitive for other developers.
> >
> > It's very important that we are on the same page. I believe a lot of
> > "format" questions will be answered by following the APIGee guidelines.
> >
> > - Mike
> >
> >
> > On Sun, Sep 15, 2013 at 6:30 PM, Chris Geer <chris@cxtsoftware.com>
> wrote:
> >
> > > Since we've been having a lot of discussions on data structures lately
> I
> > > wanted to write down what my suggestions were. These aren't 100%
> complete
> > > examples but show the relationships
> > >
> > > CRUD Interfaces
> > >
> > > Page (/pages/<page-id>)
> > > {
> > >   id: <id>,
> > >   owner: <owner>,
> > >   regionIds: [
> > >     <id>, <id>, <id>   (region order is based on order in
list, not
> field
> > > on region object)
> > >   ]
> > > }
> > >
> > > Region (/pages/<page-id>/regions/<region-id>
> > > {
> > >   id: <id>,
> > >   regionWidgetIds: [
> > >     <id>, <id>, <id>   (widget order is based on order in
list, not
> field
> > > on region widget object)
> > >   ]
> > > }
> > >
> > > Region Widget
> > > (/pages/<page-id>/regions/<region-id>/regionwidgets/<region-widget-id>
> > > {
> > >   id: <id>,
> > >   widgetId: <widgetId>,
> > >   collapsed: <collapsed>,
> > >   ...
> > > }
> > >
> > > Region Widget
> > > Properties
> > >
> >
> (/pages/<page-id>/regions/<region-id>/regionwidgets/<region-widget-id/properties/<propertyId>)
> > > {
> > >   ....
> > > }
> > >
> > > Widget (/widgets/<widget-id>
> > > {
> > >   id: <id>
> > >   title: <title>
> > > }
> > >
> > >
> > > Render Interface (custom mime-type) (Read Only)
> > >
> > > /pages/<page-id>
> > > {
> > >   id: <id>,
> > >   regions: [
> > >     {
> > >       id: <id>,
> > >       regionWidgets: [
> > >         {
> > >           id: <id>,
> > >           widgetId: <widgetId>,
> > >           title: <title>,
> > >           properties: [
> > >             {
> > >                key: <key>,
> > >                value: <value>
> > >              }
> > >           ]
> > >         }
> > >       ]
> > >     }
> > >   ]
> > > }
> > >
> > > You should also be able to render sub elements below a page so for
> > example,
> > >
> > > /pages/<page-id>/regions/<region-id> with the custom mime-type
would
> > render
> > > a single region.
> > >
> > >
> > > Obviously there is still room for uncertainty in some places. For
> > example,
> > > what happens if your have a region with three region widgets then you
> > save
> > > the region but only include two ids in the list? Personally, I think
> that
> > > should delete the missing regionWidget because that list denotes
> > ordering.
> > > The reason I don't like an "order" attribute on the sub objects is that
> > > what if you save two sub objects with the same order (which would
> happen
> > if
> > > you ever wanted to swap two objects in order because you have to update
> > > them then save each one so they would have the same order at least
> > > momentarily on the server)?
> > >
> > > Anyway, my 2-cents.
> > >
> > > Chris
> > >
> >
>

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