I'll look at it this evening. One thing you might add (and this is for anyone thinking of developing a viewer), is to define a possible project plan of stories, getting progressively more complex. As it happens, I have such a list, below. You are welcome to adopt/adapt if you wish.
Dan 0002 Representation of application (menu) services/repositories 0003 Display no-arg actions for domain services 0004 Invoke no-arg application service action returning a domain object 0005 Render domain entity title 0006 Render domain entity icon 0007 Render domain entity properties - read-only - treat all properties as strings 0008 Handle additional basic property types - integer, string, date, boolean 0009 Handle references properties - eg Customer à Address 0010 Navigate to object referenced within a property 0011 Render domain entity collections - read-only 0012 Navigate to object referenced within a collection 0013 Render no-arg actions of entity 0014 Invoke a no-arg action of an entity returning a single object 0015 Invoke a no-arg service action returning a (standalone) collection 0016 Invoke a no-arg action returning a scalar 0017 Invoke a no-arg action returning void 0018 Navigate to object referenced within a standalone action 0019 - 0025 .... stories specific to viewer technology... 0026 Invoke application service action taking simple datatypes - strings, int, date, boolean 0027 Invoke entity action taking simple datatypes - strings, int, date, boolean 0028 Invoke application service action taking reference to other object - with choices drop-down 0029 Invoke application service action taking reference to other object - with autocomplete drop-down 0030 Validate action arguments 0031 Choices for action arguments 0032 Defaults for action arguments 0033 Editable entity properties taking simple datatypes - “save-as-you-go”, single properties - similar to the NO MVC UI - strings, int, date, boolean 0034 Choices for entity properties 0035 Editable entity properties with references to other objects 0036 Validate entity properties 0037 Disable entity properties 0038 Updating multiple properties of an entity - in single request 0039 User authentication 0040 Error handling of optimistic locking failure 0041 Error handling of stale reference to deleted object 0042 Error handling of error thrown by application 0043 Extensibility: register new renderers for properties 0044 Extensibility: register new renderers for properties and action params 0045 Extensibility: register new renderers for standalone collections 0046 Extensibility: register new renderers for parented collections 0047 Extensibility: register new renderers for entities On 23 April 2013 09:21, DImuthu Upeksha <[email protected]> wrote: > Hi Dan, > Thank you. Its really helpful. I was in a doubt about that approach > and now it's clear. So I would add some detailed documents about > domain cache in near future.I shared a google doc with you that > contain the rough project proposal. Please give me some comments to > make it better and if there are some incorrect or unrelated facts > please tell me so that I can re-correct them. Specially there could be > more deliverables than I mentioned which you want from this project. > > Thanks > Dimuthu > > On Mon, Apr 22, 2013 at 11:32 PM, Dan Haywood > <[email protected]> wrote: > > Hi Dimuthu, > > You are basically correct, and the algorithm is something like you > describe > > it. > > > > I'd reverse the order of the steps, though. > > > > First, use the describedBy link to find the datatype of the parameter (or > > the property, for an object form), eg to walk through [1] > > If it's a primitive/built-in (date, string, int etc), then you know the > > widget to use to render the value. > > If it's not, then you've either got an enum or a reference to an entity. > > In both cases, look for choices. for an enum this will be a list of > > strings, for an entity it will be a list of hrefs. > > > > What we haven't talked about is how to specify a reference to an entity > as a > > parameter, for example [2]. In this case, you'll probably need to look > for > > an autoComplete method to use. Note: the autoComplete idea arose after I > > wrote the RO spec, so it might be a bit tricky to figure out. We can > always > > consider extending the representations to handle this. > > > > Looking forward to reading your proposal, > > > > Cheers > > Dan > > > > > > [1] http://localhost:8080/restful/domainTypes/dom.todo.ToDoItem$Category > > [2] > > > http://localhost:8080/restful/objects/TODO:L_0%5E1:sven:1366698570680/actions/add > > > > > > On 23 April 2013 06:36, DImuthu Upeksha <[email protected]> > wrote: > >> > >> Hi Dan. > >> > >> Yes. In parameters map there is choices list. Then I can understand > >> that it is a list to be shown (In gui : A combo box). But when we look > >> at the other two attributes (num :0 ,num :2) there is not a way to > >> understand what should be the input type (a text box, date picker or > >> other UI element). So what I understood is, we have to dig in to the > >> "described by" link and find out data types of other two data > >> parameters. Then the logic is > >> > >> 1. First look in to parameters map and look for properties with > >> "choices" tag. If so, in gui level it should be a combo box with > >> values in "choices" tag. > >> 2. For other properties with not having "choices" tag you have to find > >> out its data types by looking in to "described by" link. [1] >> [2] >> > >> [3] >> [4]. Then I can find the data type. (In this case it is a > >> String) > >> > >> Though this is a simple logic I feel bit confused. This approach may > >> be ok to this scenario. But may not compatible with some cases (I feel > >> so). Please tell me if I'm wrong. > >> > >> As soon as I solve this problem I will start writing my proposal > >> because the application period has started. > >> > >> [1] http://localhost:8080/restful/services/toDoItems/actions/newToDo > >> [2] > >> > http://localhost:8080/restful/domainTypes/objstore.jdo.todo.ToDoItemsJdo/actions/newToDo > >> [3] > >> > http://localhost:8080/restful/domainTypes/objstore.jdo.todo.ToDoItemsJdo/actions/newToDo/params/Description > >> [4] http://localhost:8080/restful/domainTypes/java.lang.String > >> > >> Thank You > >> Dimuthu > >> > >> On Sun, Apr 21, 2013 at 11:22 PM, Dan Haywood > >> <[email protected]> wrote: > >> > > >> > > >> > On 21 April 2013 22:52, DImuthu Upeksha <[email protected]> > >> > wrote: > >> >> > >> >> Sorry this is the second part of previous mail > >> >> > >> >> description : java.lang.String > >> >> category : dom.todo.ToDoItem$Category > >> >> due by : org.joda.time.LocalDate > >> >> > >> >> for description and due by properties we can set a Text box and date > >> >> picker because they have known data types. But for category, > >> >> "dom.todo.ToDoItem$Category" is not a known type. Actually what > should > >> >> come here is a combo box. Problem is how can I figure it out? > >> >> > >> > > >> > Looks like you are making good progress if you are asking these sorts > of > >> > questions! > >> > > >> > To answer the question, then: if you browse to > >> > http://localhost:8080/restful/services/toDoItems/actions/newToDo you'll > >> > see > >> > that in the "parameters" map (for num=1) the "choices" array lists the > >> > available values. > >> > > >> > Internally, this corresponds to the ActionParameterChoicesFacet > (there's > >> > also a PropertyChoicesFacet) in the metamodel. > >> > > >> > I like to test these things using the "Rest Console" extension for > >> > Chrome > >> > (there are many other similar extensions). So, if you specify the > >> > target > >> > url of: > >> > > >> > > http://localhost:8080/restful/services/toDoItems/actions/newToDo/invoke > >> > > >> > and a body of: > >> > > >> > { > >> > "description": "Test", > >> > "category": "Professional", > >> > "dueBy": null, > >> > "cost": null > >> > } > >> > > >> > and submit as a POST, then the new object should be created. > >> > > >> > HTH > >> > Dan > >> > > >> > > >> >> > >> >> On Sun, Apr 21, 2013 at 2:43 PM, DImuthu Upeksha > >> >> <[email protected]> wrote: > >> >> > Hi Dan > >> >> > Yes I think that domain cache is one of the risky areas. Specially > >> >> > assigning android data types to properties of Domain objects. I > have > >> >> > a > >> >> > rough plan for that but have some unclear areas also. > >> >> > > >> >> > Say I need to add newToDo through > >> >> > "http://localhost:8080/restful/services/toDoItems/actions/newToDo"; > >> >> > So I need to add some parameters (description,category,dueBy) > before > >> >> > invoking this. > >> >> > > >> >> > Then I should create an interface to fetch those parameters. > >> >> > > >> >> > What I can do is searching the data types of those params through > >> >> > "described by" link > >> >> > > >> >> > > >> >> > " > http://localhost:8080/restful/domainTypes/objstore.jdo.todo.ToDoItemsJdo/actions/newToDo > " > >> >> > > >> >> > Then I can get canonicalNames of each parameter. > >> >> > > >> >> > > >> >> > > >> >> > On Sat, Apr 20, 2013 at 2:14 PM, Dan Haywood > >> >> > <[email protected]> wrote: > >> >> >> > >> >> >> On 20 April 2013 08:32, DImuthu Upeksha < > [email protected]> > >> >> >> wrote: > >> >> >>> > >> >> >>> > >> >> >>> 1. As I'm new to Isis project I don't know coding conventions you > >> >> >>> use. > >> >> >>> Like packaging and naming classes > >> >> >> > >> >> >> > >> >> >> Our dev env standards are documented here [1]. There are some > >> >> >> templates etc > >> >> >> that you can import into Eclipse. If you use some other IDE, > then > >> >> >> sorry, > >> >> >> we don't have any for those. > >> >> >> > >> >> >> In terms of package names, if we assume that eventually your code > >> >> >> will > >> >> >> become part of the Isis codebase, then the package name would be: > >> >> >> > >> >> >> org.apache.isis.viewer.android.xxx > >> >> >> > >> >> >> But you might want to put the code under a domain that you own > >> >> >> initially, eg > >> >> >> replacing "org.apache.isis" with (your equivalent of) > >> >> >> "com.danhaywood". > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >>> > >> >> >>> 3 If you can give me a existing project which has a good > packaging > >> >> >>> structure, (a github link) I will be able to refer it and have a > >> >> >>> clear > >> >> >>> idea. > >> >> >> > >> >> >> > >> >> >> My best suggestion is for you to look at Isis itself [2]. In > >> >> >> particular, > >> >> >> look at the viewers (wicket, restfulobjects, scimpi). > >> >> >> > >> >> >> Right now I wouldn't worry about this stuff too much. It's good > >> >> >> that > >> >> >> you > >> >> >> are thinking about it, but it's not where the project risk lies. > If > >> >> >> I > >> >> >> were > >> >> >> you I'd focus on exploring things that you think are difficult to > >> >> >> do, > >> >> >> and > >> >> >> spike them. Always better to fail early than late... > >> >> >> > >> >> >> Cheers > >> >> >> Dan > >> >> >> > >> >> >> > >> >> >>> > >> >> >>> > >> >> >>> Thanks > >> >> >>> Dimuthu > >> >> >>> > >> >> >> > >> >> >> [1] > http://isis.apache.org/contributors/development-environment.html > >> >> >> [2] https://github.com/apache/isis > >> >> > > >> >> > > >> >> > > >> >> > -- > >> >> > Regards > >> >> > > >> >> > W.Dimuthu Upeksha > >> >> > Undergraduate > >> >> > > >> >> > Department of Computer Science And Engineering > >> >> > > >> >> > University of Moratuwa, Sri Lanka > >> >> > >> >> > >> >> > >> >> -- > >> >> Regards > >> >> > >> >> W.Dimuthu Upeksha > >> >> Undergraduate > >> >> > >> >> Department of Computer Science And Engineering > >> >> > >> >> University of Moratuwa, Sri Lanka > >> > > >> > > >> > >> > >> > >> -- > >> Regards > >> > >> W.Dimuthu Upeksha > >> Undergraduate > >> > >> Department of Computer Science And Engineering > >> > >> University of Moratuwa, Sri Lanka > > > > > > > > -- > Regards > > W.Dimuthu Upeksha > Undergraduate > > Department of Computer Science And Engineering > > University of Moratuwa, Sri Lanka >
