View Source

h1. Notes
* When something is added in the DMS (document, image, comment, etc.) it *has to be* associated with an parentURI (e.g. painting or sub-object of it; or a parent comment). The alternative is to allow DMS objects to exists independently, but this was discussed and decided against on the 3.1->3.2 meeting (BTW, this simplifies the API because there will be no need for attach/detach events to be handled);

* The API will be expressed as notifications/events (e.g. notifyObjectAdded) that will be invoked from the UI after sth happens. For example when the user uploads a new file, the UI will notify the backend for that;

* Transactions will not be supported, because it will be simpler and it seems against the nature of the events (for the above example, when the user uploaded the new file, and the DB update fails, the DMS cannot revert the operation);

* Some notifications will include the corresponding dmsId (nuxeo-uid);

* Add- methods will return the URI of the new object

* Supported objects
|| Object type || Content || dmsID ||
| Comment | + | - |
| Document | + | + |
| Image | - | + |

* When a comment is attached to a specific property, the call should include that property as well. In the general case when the object is attached to the painting, the property URI could be null. The combination of parentURI and propURI is called a *Place* below.

* Q: How the UI/DMS knows the URI of the parent and the property? Hope this comes from the RForms rendering...

h1. API

h2. Use cases
* Add object
notifyObjectAdded(place, type, content, dmsId)

* Edit object
notifyObjectUpdated(place, content, dmsId)
Q: Do we need the place? Maybe not, but if can be specified by the caller this may simplify the update query on the backend

* Reply to object (comment)
notifyObjectAdded(place, type, content, dmsId)
where parentURI=parent comment or Painting

* Delete object
notifyObjectDeleted(place, dmsId)

h1. Backend functionality impl. notes
h2. Data model