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.
> > >
> >
>
