OK. Could you notify me (@johan_andries or email) as soon as it's in the Subversion trunk?
On Tue, Nov 1, 2011 at 3:36 PM, Dan Haywood <[email protected]>wrote: > Richard and I have been chatting off-list, and our view is that the spec > should be changed in order to accommodate implementations (like Isis) that > wish to return the list of changed objects. > > So, the RO spec is going to say, > > given: > > class Customer { > Order newOrder() { > var order = newTransientInstance<Order>(); > order.Customer = this; > persist(ref order); > return order; > } > } > > when invoking ~/objects/CUS-123/actions/newOrder/invoke > > then the representation is: > > Content-Type: application/json;profile=urn:org.restfulobjects/actionresult > <<< a new representation/profile type > { > links: [ > { > rel: self, > href: ~/objects/CUS-123/actions/newOrder/invoke, > ... > } > ], > returns: { > rel: domainobject > href: ~/objects/ORD-001, > type: application/json;profile=urn:org.restfulobjects/domainobject > value: { > // this is where the representation of the returned Order would go, > inlined (as per an x-ro-follow-links) > } > } > ... > extensions: { > .. > } > } > > For actions that returns lists, scalars or void, the structure would > basically be the same, but the contents of "returns.value" json-property > would be different (ie a list representation or a scalar representation, > etc). > > In the case of Isis, the extensions property will have a list of links to > changed objects: > > "extensions": { > "changedObjects": [ > { "rel": "domainObject", "href": " > http://localhost:8080/objects/OID-123"; > ...}, > { "rel": "domainObject", "href": " > http://localhost:8080/objects/OID-456"; > ...}, > ] > > However, this is implementation-specific, and won't be in the spec. > > I'll try to implement this this evening; it shouldn't be difficult. So > don't waste time on a work-around. > > Cheers > Dan > > > > On 1 November 2011 14:28, Johan Andries <[email protected]> wrote: > > > The RO spec is also mentioning ETags. Could that be a temporary > workaround > > for this problem? I could keep a list of all domain objects present in > the > > browser, and GET all of them after each action. > > > > Johan. > > > > On Tue, Nov 1, 2011 at 11:21 AM, Dan Haywood > > <[email protected]>wrote: > > > > > On 1 November 2011 10:10, Johan Andries <[email protected]> > wrote: > > > > > > > Hi, > > > > > > > > if I do an object action using the json-viewer, is there a way to > get a > > > > list of all the the objects whose state has been changed as a > > side-effect > > > > of that action? > > > > > > > > > Good question. The short answer is no, not currently. But it could... > > > > > > > > > > > > > > > > That way the impacted object views can be updated in the > > > > javascript application. > > > > > > > > > > > > > Is this kind of system used in the DnD > > > > implementation? > > > > > > Yes... more generally, there is an ObjectNotifier component that keeps > > > track of dirtied objects, and this can be used to notify the viewers to > > > repaint themselves. > > > > > > So the information is there. But we need to figure out how to return > it. > > > > > > The obvious thing to do is to add a custom extension, eg: > > > > > > "extensions": { > > > "changedObjects": [ > > > { "rel": "domainObject", "href": " > > > http://localhost:8080/objects/OID-123"; > > > ...}, > > > { "rel": "domainObject", "href": " > > > http://localhost:8080/objects/OID-456"; > > > ...}, > > > ] > > > } > > > > > > However, one snag is that, in the case of an action returning a single > > > domain object, the RO spec says to return the domain object itself, > > rather > > > than a representation of an action result that references the domain > > > object. My gut feeling is that, if we were to use extensions as I > > describe > > > above, then it would be wrong to put that "changedObjects" list on the > > > domain object's representation; they really belong to the results of > the > > > action. > > > > > > Thus, I'm thinking we would need to change to the RO spec, so that an > > > action always returns its own representation. (Indeed, even a void > > action > > > should return a representation, now that I think of it... to indicate > any > > > changed objects). > > > > > > Richard... what's your view? > > > > > > > > > Dan > > > > > > > > > > > > > > > > > > > Any hints? > > > > > > > > Thank you! > > > > > > > > Johan. > > > > > > > > > >
