Mailing-List: contact isis-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: isis-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4E06410D.3010200@nakedobjects.org>
Date: Sat, 25 Jun 2011 21:11:57 +0100
From: Robert Matthews <rmatthews@nakedobjects.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Thunderbird/3.1.10
MIME-Version: 1.0
To: isis-dev@incubator.apache.org
Subject: Re: a JSON-based RESTful protocol.
References: <4DF7D51D.2060802@gmail.com>
 <BANLkTik7kdvviN1TMr86eE9m9aZG1Cmzgw@mail.gmail.com>
 <4E05B12E.2050808@nakedobjects.org>
 <BANLkTinnOZisAMUyccTJt6hRmMUoUOFCQg@mail.gmail.com>
In-Reply-To: <BANLkTinnOZisAMUyccTJt6hRmMUoUOFCQg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

The point is you can deal with them as exceptions, but that list will 
typically be small or hopefully non-existent. Also, if there were to be 
many then it wouldn't be the right choice, and you'd put the work in to 
define all.  Different situations call for different solutions.

On 25/06/11 14:49, Alexander Krasnukhin wrote:
> I have a very bad bad feeling about assuming all the class names are unique.
>
> On Sat, Jun 25, 2011 at 11:58 AM, Robert Matthews<
> rmatthews@nakedobjects.org>  wrote:
>
>> 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 names.
>>
>> 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.
>>
>> Regards
>> Rob
>>
>>
>> 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<dkhaywood@gmail.com>   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]
>>>> https://cwiki.apache.org/**confluence/display/ISIS/**
>>>> Viewer-agnostic+Network+**Protocol<https://cwiki.apache.org/confluence/display/ISIS/Viewer-agnostic+Network+Protocol>
>>>> [2] https://cwiki.apache.org/**confluence/display/ISIS/**
>>>> Restful+Json+Protocol<https://cwiki.apache.org/confluence/display/ISIS/Restful+Json+Protocol>
>>>> [3] https://cwiki.apache.org/**confluence/display/ISIS/GET+**
>>>> on+an+Object<https://cwiki.apache.org/confluence/display/ISIS/GET+on+an+Object>
>>>>
>>>>
>>>>
>>>>
>