rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Gornstein <...@gornstein.com>
Subject Re: Rave Data Structures
Date Mon, 16 Sep 2013 15:55:46 GMT
On Mon, Sep 16, 2013 at 11:27 AM, Michael Jett <mikesjett@gmail.com> wrote:

> 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)
> >
>
> Why would we define a custom mime-type other than JSON?
>

Let Chris tell me if I am wrong, but I assume this is so you can have the
read-only endpoint with the same URL structure of '/pages/<page-id>' but
have one be read only and have one be the regular rest endpoint which can
take post and put.

>
>
> >
> > /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.
> >
> >
> This makes sense. It's possible to map this to an angular $resource.
>

I understand you can map this to an angular resource, but this means when
calling save you either have to remove the read-only properties before
saving, or save them with them there to the correct update endpoint just
ignoring them on the server.

If you are going to leave the read-only properties attached when saving, I
don't see what we get from the read-only endpoint instead of just adding a
few immutable fields to the REST model.

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

Dan

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