On 04/11/2011 08:55, Johan Andries wrote:
It is my goal to put a first version (just a zip file) of the
javascript application online by the end of next week. After that I'll
create a Google code project to host it more officially.
Good stuff.
Two remarks about the polymorphism question:
1. http://~/domainTypes/org.apache.isis.example.claims.dom.employee.Employee
would have to list all super classes (and interfaces it implements),
not all sub classes as you mention. In this example that would be the
two interfaces Claimant and Approver. I am not sure that would not
scale.
You are right that this is a bounded set and so ought to scale
reasonably well. But some of the lists could be quite large (especially
if we included transitive dependencies so that the client didn't have to
walk all the way up the hierarchy). So this implementation is going to
be ugly.
I'm not going to rule out this approach for good, but I think the need
can be addressed by (2) below - let me expand on it there.
2. isAssignableFrom is a technical action without real business
meaning, so it must not be offered to end-users in the UI. Isn't that
a bit inconsistent?
I guess I didn't explain this properly. I wasn't suggesting that this
action would be available on the DomainObject resource; rather it is
available as a brand-new resource linked from the DomainType resource.
I've just gone ahead and implemented (and committed) this, though I
haven't yet updated the docs. Still, if you do a GET on the DomainType,
you'll see a new "typeActions" list, which lists the different type
actions you can invoke; eg:
http://localhost:8080/domainTypes/org.apache.isis.tck.objstore.dflt.scalars.ApplibValuedEntityRepositoryDefault
will return:
"typeActions" : [ {
"id" : "isSubtypeOf",
"rel" : "typeaction",
"href" :
"http://localhost:8080/domainTypes/org.apache.isis.tck.objstore.dflt.scalars.ApplibValuedEntityRepositoryDefault/typeactions/isSubtypeOf/invoke";,
"method" : "GET",
"type" :
"application/json;profile=\"urn:org.restfulobjects/domaintypeissubtypeof\"",
"arguments" : {
"supertype" : {
"href" : null
}
}
} ],
This can then be invoked in the usual way, ie passing the arguments map
as a URL-encoded map for a query string called args.
Eg to check that the above type IS a subtype of itself, you can use:
http://localhost:8080/domainTypes/org.apache.isis.tck.objstore.dflt.scalars.ApplibValuedEntityRepositoryDefault/typeactions/isSubtypeOf/invoke?args=%7B%20%22supertype%22%20%3A%20%7B%20%20%22href%22%20%3A%20%22http%3A%2F%2Flocalhost%3A8080%2FdomainTypes%2Forg.apache.isis.tck.objstore.dflt.scalars.ApplibValuedEntityRepositoryDefault%22%20%20%7D%20%7D
ie, args is the URL encoded version of
{ "supertype" : { "href" :
"http://localhost:8080/domainTypes/org.apache.isis.tck.objstore.dflt.scalars.ApplibValuedEntityRepositoryDefault";
} }
(I'm using a little online utility
http://www.albionresearch.com/misc/urlencode.php) to encode/decode maps.
3. The js application would have to call this isAssignableFrom action
right at the moment that the user tries to drop an Employee object on
a Claiment or Approver form field.
That's true, it would. I don't see this as an issue.
Of course I could cache previous
calls to isAssignableFrom.
Yes, though the representation also has a cache-control of 1 day set, so
the web browsers caching (or cache proxies) should take care of this
rather than being write something yourself.
Conclusion: I would like to ask you to reconsider my original
suggestion (item1 in the list above)...
Can you see how you get on with (2); if it's unworkable, then we can
revisit (1).
Thx
Dan
Johan.
On Fri, Nov 4, 2011 at 9:24 AM, Dan Haywood
<[email protected]> wrote:
Interesting question.
Rather than listing all subtypes - which I think would not scale
particularly well - I think it would be better to have an action,
equivalent to java.lang.Class#isAssignableFrom(java.lang.Class). This
would allow a client to ask whether the Employee is compatible with the
Claimant interface.
In other words:
{
"href": "http://
~/types/com.mycompany.myapp.claims.Claimant/actions/isAssignableFrom/invoke",
"arguments": {
"href": "http://~/types/com.mycompany.myapp.employee.Employee";
}
}
Thoughts?
~~~
Question back to you: do you intend to open source your Javascript app?
I'd be very interested in seeing it, at any rate.
Cheers
Dan
On 4 November 2011 07:13, Johan Andries<[email protected]> wrote:
Hi,
in the claims example application the class
org.apache.isis.example.claims.dom.claim.Claim
is using the interfaces
org.apache.isis.example.claims.dom.claim.Claimant
org.apache.isis.example.claims.dom.claim.Approver
both implemented by
org.apache.isis.example.claims.dom.employee.Employee
The problem is now that my javascript application does not know about
the polymorphic relationship between the Employee class and the two
interfaces, so in this case I have no way of enforcing type safety in
the UI when invoking actions or updating properties.
One way of solving this would be to specify all implemented interfaces
and superclasses for a given domain type in chapter 20 (Domain Type
Resource) of the restful objects spec (v0.50). For example,
http://~/domainTypes/org.apache.isis.example.claims.dom.employee.Employee
should list all other domain types it can act as.
Or is there an other solution I am not aware of?
Johan.
