incubator-isis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Matthews <>
Subject Re: a JSON-based RESTful protocol.
Date Sat, 25 Jun 2011 09:58:06 GMT
I've noticed a similar thing in a help index that I have had to 
implement recently.  While starting off with a set of fully qualified 
class names I noticed that for the domain classes (where the class was 
ultimately accessed by the user) we never used the same name as this 
would be confusing to the user. With that in mind we now assume that all 
the class names are unique so can safely refer to them using their short 

Now as Dan said, these will depend on the OID in question but we might 
want to adapt its interface so it can provide both the original internal 
form and a suitable user identifiable form.  So in the original example 
com.mycompany.Order|123 would be available as Order|123 and Dan's JPA 
example, ORD|123 would also become Order|123.


On 24/06/11 19:38, Henry Saputra wrote:
> Hi Dan,
> Is there a way to map the actual Java class name for the object such
> as com.mycompany.Order|123 to short name? This will help to make the
> API URL simpler.
> I am new with Apache Isis and naked object design but looking forward
> to implement it as prototype for our architecture.
> - Henry
> On Tue, Jun 14, 2011 at 2:39 PM, Dan Haywood<>  wrote:
>> Alexander and I have (off-list) been throwing an idea or two about
>> developing a viewer-agnostic network protocol.  Alexander put a page on the
>> wiki about this a while back [1].
>> My thought are that we could support this using a JSON-based RESTful
>> protocol, perhaps as an extension/evolution of our current Restful viewer
>> (which currently supports only XHTML).
>> With that in mind, I've added a number of pages to the wiki to document what
>> this protocol might look like; [2] is the jumping off point, but see also
>> [3] for details on the typical representation of a domain object.
>> Comments/contributions welcome!
>> Dan
>> [1]
>> [2]
>> [3]

View raw message