Hi all, > a property/field (or action/operation parameter) being required is just > one sort of validation. Others include @Regex, @MinLength, @MaxLength etc.
Ah, got it. As I said before, I am aiming for a more disconnected/snapshot-based approach (which is more friendly to a high latency protocol), so I am planning for no callbacks, just as you probably did with RO? Instead, the metadata ought to provide enough information so the client can perform the required validations itself (and only if they want/know how - the API will validate the data again when accepting it). So in your example, minRequired, maxRequired, and regexp will have to be exposed in the schema itself, as isRequired is. > In Isis visibility is computed dynamically. It might vary based upon the > state of the object (eg hide the "complete" action for a todo item that is > already complete) Right, action enablement is currently computed ahead of time and is available as a map in Instance. [1] >From what I read here, it seems that my goals with Kirra are more related to RO than to Isis per se (as Isis design assumes client and provider are in the same process and there is no latency), although I could still see it working with an Isis implementation with some loss of functionality. Re: the Google hackathon, was mostly a learning exercise for me, 1st time doing anything on Android. We got as far as having an app showing entities, instances and instance details as retrieved from a back end application via its REST API. Some screenshots in the slides from our end-of-hackathon demo presentation [2]. Cheers, Rafael [1] https://bitbucket.org/abstratt/kirra-api/src/master/com.abstratt.kirra.api/src/com/abstratt/kirra/Instance.java?at=master#cl-75 [2] https://docs.google.com/presentation/d/1jRg6-jHe2yZXWwrbRSizQ5P9OK6Ff34xXiydGfSgskM/present#slide=5
