You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Tools like Airtable and Notion have re-defined how we think about tables. With these tools, users can:
Change the columns and set custom properties with constrained datatypes
Configure sorting / filter / view types, and share these views
Easily create / instantiate / edit data from within this view
In Atomic Data, we already have Collections that can be shown in a Table component (in Atomic Data Browser). However, Tables could offer some extra features:
Constrain Classes. All children need to be instances of some particular Class. This prevents setting the Class as a child, though. We could also only constrain members instead of children.
Support a regular-old JSON (without long HTTP urls) REST API that accepts POSTing to /new or something. Because we have Class constraints, we don't need to use long URLs in properties. Also, we could scope tokens / authorization to this collection, and remove the need for Commits.
Custom Views. A view contains information about filter / sort / displayed properties. This is what airtable and notion do.
Hierarchy guarantees. Queries always are the parents of their children, contrary to Collections which often just query over existing items. Maybe this means it always filters data in some particular way.
More thoughts:
Collections seems to insinuate some form of ownership, so maybe these should be renamed to Queries (thanks @Polleps)
If you create a table and edit its columns, are you in fact editing a Class? I'd assume so. And is this Class a child of the Table? This would not work if you constrain the children of a table.
So, how to achieve this?
Extend the existing Collection class
The Collection Class already allows for filtering by property / value, sorting on any property.
Maybe adding fields for view (e.g. grid, or some custom thing) makes sense?
But how should we indicate that it filters by parent? We could introduce a parent filter, which is an optional resource that performs a filter in the Query.
Adding a new Table class
The Table:
class the required class, containing the required and recommended properties
view the default view (e.g. table / grid / list). Maybe we also have a list of availableViews
members the list of child resources. We could only show items here that are both children as well as fitting the shape of the table.
newendpoint that allows posting a new resource to this table.
The View:
properties order or properties shown in header (question: how does this relate to properties in the class? Must they be the same? What if there are more properties in the Table, does that mean these are required?)
sort, filter, pagination... all the collection stuff
Authorization / rights and appending
Let's say I want to add a new or an existing item to a table, such as a Comment to some ChatBox. How do I do this?
We probably don't just want to determine who can read and edit tables, but also who can add items to it. I think we'll need a new right. #96
We could set the parent of the Comment to the ChatBox's Table.
No extra properties required, because parent is always required. Seems clean!
But what if you don't want the one controlling the Table to control all its items? For example, if you start a Thread you might not want to give the creator of the thread edit rights to all resources.
Should we allow users
The text was updated successfully, but these errors were encountered:
joepio
changed the title
Tables / constrained and highly customizable collections
Tables: constrained and highly customizable collections
Jun 30, 2021
Tools like Airtable and Notion have re-defined how we think about tables. With these tools, users can:
In Atomic Data, we already have
Collections
that can be shown in a Table component (in Atomic Data Browser). However,Tables
could offer some extra features:Class
as a child, though. We could also only constrain members instead of children./new
or something. Because we have Class constraints, we don't need to use long URLs in properties. Also, we could scope tokens / authorization to this collection, and remove the need forCommit
s.Views
. A view contains information about filter / sort / displayed properties. This is what airtable and notion do.Collections
which often just query over existing items. Maybe this means it always filters data in some particular way.More thoughts:
Collections
seems to insinuate some form of ownership, so maybe these should be renamed toQueries
(thanks @Polleps)Class
? I'd assume so. And is thisClass
achild
of theTable
? This would not work if you constrain the children of a table.So, how to achieve this?
Extend the existing Collection class
The Collection Class already allows for filtering by property / value, sorting on any property.
Maybe adding fields for
view
(e.g. grid, or some custom thing) makes sense?But how should we indicate that it filters by parent? We could introduce a
parent
filter, which is an optional resource that performs a filter in the Query.Adding a new Table class
The
Table
:class
the required class, containing the required and recommended propertiesview
the default view (e.g. table / grid / list). Maybe we also have a list ofavailableViews
members
the list of child resources. We could only show items here that are both children as well as fitting the shape of the table.new
endpoint that allows posting a new resource to this table.The
View
:properties
order or properties shown in header (question: how does this relate to properties in the class? Must they be the same? What if there are more properties in the Table, does that mean these are required?)sort
,filter
,pagination
... all the collection stuffAuthorization / rights and appending
Let's say I want to add a new or an existing item to a table, such as a Comment to some ChatBox. How do I do this?
We probably don't just want to determine who can read and edit tables, but also who can add items to it. I think we'll need a new right. #96
We could set the
parent
of the Comment to theChatBox
's Table.No extra properties required, because
parent
is always required. Seems clean!But what if you don't want the one controlling the Table to control all its items? For example, if you start a
Thread
you might not want to give the creator of the thread edit rights to all resources.Should we allow users
The text was updated successfully, but these errors were encountered: