On 02/11/2011 07:51, Johan Andries wrote:
OK. Could you notify me (@johan_andries or email) as soon as it's in the
Subversion trunk?
Just committed something now.
This is against v0.49, which I uploaded this morning to
http://restfulobjects.org. The main change is the new actionresult
representation (section 19.4), which inlines representations of the
list, scalar or domain object.
It's within this actionresult repr that the changed objects are listed.
Note that this is an Isis proprietary extension; ie there's no mention
of this in the spec.
Currently the spec says that void actions return a 204 (no content), but
I realised this morning that they too should return an actionresult.
That's because, even though there's no inlined returned representation,
we still want the extensions map in order to attach the changed objects etc.
I'll look into that this evening; shouldn't be a big deal.
Cheers
Dan
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.
