- 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...
- Add object
- Edit object
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)
- Delete object