Hi Dan The "OK" button is one which is shown on UI for that domain action. It is associated with the action. But when the next form is presented with the "EDIT" button and then "OK" button, this "OK" button has no associated action. So pressing the "OK" button has no effect. Here is a flow.
Action --> Screen A, enter data and press "OK" --- > Screen B, press "EDIT", enter data and press "OK" -- > Still on Screen B with "EDIT" button Question Screen B "OK" button loops on same screen. Can this behaviour be changed? Thanks Dharmesh -----Original Message----- From: Dan Haywood [mailto:[email protected]] Sent: Friday, January 10, 2014 10:36 AM To: users Subject: Re: ISIS Actions On 10 January 2014 09:53, Chohan, Dharmesh <[email protected]> wrote: > Hi > > As I understand actions are presentenced via the top level menu options. Yes. To be a little more precise, the actions of the registered domain services (in isis.properties) are shown as items of the top level menu. The actions of the entity are shown as buttons either to the right of its icon/title, or near to the property/collection with which the action is associated. This can be done either using @MemberOrder annotation, or using JSON, see [1, 2]. > I want to call a DomainX action from a button "OK" which is generated > by the framework. In my case I have DomainA action calling DomainB. > You do something in DomainB screen, edit and then press the "OK" button. > > How can map the "OK" button to some other DomainX action. Is this > possible? > > I'm not quite sure what this "OK" button is, do you mean an action called ok() on DomainA? If so, then to answer your question, then it is not possible to map the button to some other domain object; that would violate the layering of responsibilities that Isis enforces. Instead, have your domain object A call domain object B: public class DomainObjectA { public void ok() { DomainObjectB b = .... /// get hold of b.doSomething(); } } But perhaps I've misunderstood what you wanted. ~~~ Isis also supports the notion of contributed members (properties, collections, actions). This might also support your use-case (and is a very powerful technique, somewhat akin to using traits). There's some information about it at [3] HTH Dan [1] https://isis.apache.org/core/dynamic-layouts.html [2] https://github.com/apache/isis/blob/master/example/application/quickstart_wicket_restful_jdo/dom/src/main/java/dom/todo/ToDoItem.layout.json [3] http://isis.apache.org/applib-guide/how-tos/how-to-01-062-How-to-decouple-dependencies-using-contributions.html > Thanks > Dharmesh > > > > > >
