Hi Steve, The short answer is that Isis does not support this use case.
The longer answer is that earlier versions of Isis - going back to when it was Naked Objects for Java - did support the use case. But supporting it adds a lot of complexity into the framework for very little benefit. Since moving to Apache we've been consistently trying to simplify the framework, I've made some further remarks within the body of your mail, perhaps give you some ideas on how we would normally approach this... On 5 June 2015 at 12:55, Stephen Cameron <steve.cameron...@gmail.com> wrote: > Hi, > > *I am using the Isis Wicket viewer for a demo application.* > > I have a scenario where I wish to create a new object with mandatory > properites, the simpleapp demo shows how to initialise an object via an > action on the repository which is done with one form, ... in other words, the action prompt > then when you access > the new object later on, its via another form, its 'own' bigger form > > .. in other words the object page itself. > So its seems to me that all object creation requirest two forms one to > create an object and another to maintain it. ... although you can use Isis for CRUD style applications (and it annoys me intensely when Isis is characterized as *only* being suitable for CRUD), over the years we've found it generally works better to restrict changes to actions and turn off the object edit feature completely. In 1.8.0 we actually added formalized support for this through the "isis.objects.editing" property [1] In the Estatio app [2] we took the decision to make all objects (migrated from the system we were replacing) immutable by default; so that when the users said "why can't I change this field here?" we could use that as the basis of a "and why do you need to do that?" It allowed us to do much better analysis uncovering the implicit as well as explicit business processes that needed to be supported. And of course, given how quickly features can be added in Isis, we were very often able to ship a new version of the app with the new action to the users within a very short timescale (ie later that day...). > This is fine untill the object > has many mandatory properties, all must appear in the create form or you > get an error when the repository tires to persist the new object, so the > creation form starts to become as complex as the maintenance form. > > Several comments about this. First, if these are really big complex objects, are they perhaps they are too big? Should they not be broken out into smaller objects? Second, if there are reasonable defaults for properties that can be computed, then either use the defaultNXxx(...) supporting methods for the action parameters, or simply don't show those parameters and let the user adjust later. Third, if there is lots of information to be entered, you might consider using a view model rather than a single prompt. That will allow you to build a wizard. We've made a start on this (though admittedly not completely finished at [3]). > Given that the forms are generated this is not a big problem in terms of > effort to set up, its more the difference in behaviour of a Isis > application to what users are familiar with. Normally this would be the > same form with mandatory fields marked, you'd not be able to submit it to > create a new object without filling in all the mandatory fields. > > Si I think I am wanting the repository class to create a transient object, > show that objects maitenance form to the user, and have them save it back > to the repository for persisting. Can this be done? > > ... so to conclude, no, this isn't supported. It would be possible to support in Wicket viewer, and indeed earlier prototypes did have that feature, but we feel it's just not worth complexity. Moreover, for the Restful Objects viewer, which is of course stateless, there is no obvious equivalent... handling of the transient state becomes the responsibility of the client, which doesn't help anyone. This is why we prefer view models... the state to be managed is basically part oft the URL. Hope all that helps a little... Cheers Dan > Perhaps I need to understand object lifecycle better? > > Thanks > Steve Cameron > [1] https://github.com/apache/isis/blob/23fd0eea875d830d94d845477451e05347fe1db1/example/application/simpleapp/webapp/src/main/webapp/WEB-INF/isis.properties#L257 [2] https://github.com/estatio/estatio [3] https://github.com/isisaddons/isis-wicket-wizard
