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 Mon, 16 Sep 2013 16:49:20 GMT
On Mon, Sep 16, 2013 at 3:55 AM, Dan Gornstein <dan@gornstein.com> wrote:

> Chris,
>
> How will this work in terms of saving the data in angularJS?
>
> Currently we are taking advantage of the angular resource objects, breaking
> down the pages for render endpoint into their individual resources (pages,
> regions, and regionWidgets).
>
> If you want to manipulate the data, for instance collapse a widget and save
> that state back to the server, all you need to do is change the collapsed
> property of the RegionWidget resource object and call regionWidget.$save();
>
> If we go to a readonly endpoint to get the data for rendering pages, will
> we then need to make another call to get the model which you can manipulate
> and update? Or will we have to manipulate the object before sending it back
> to the update endpoint?
>
> I was hoping you could explain a bit about the benefits we get out of
> having the different read-only model type, and how updates will work on the
> client side.
>

Dan, we are coming at this from two different perspectives. I understand
that Angular prefers the backend to operate a particular way, however I'm
more concerned with providing a consistent backend set of services,
regardless of the UI technology we use. In my opinion, the render resource
could be UI specific but I'm not sure the CRUD interfaces should be.

In regards to the render, read-only made sense to me because it gave you a
giant nested rich object. That being said, if we want to make it
read-write, I don't have a problem with that, it could just be complicated
to manage it. There are a lot more moving parts with a highly nested data
structure.

Chris

>
> Thanks,
> Daniel Gornstein
>
>
> 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