Hi Dan, I am coming around to your perspective on this, if you stay in the OO frame of mind an action that collects data to enable creation and intialisation of a new object can be thought of as a constructor for that object, which is to say you cannot create a new object with a no-args constructor as part of the model design.
This has some relevance to another post where I asked about adding new objects in the process of adding object references to a collection. That 'constructor' action prompt then becomes what the user expects to see wherever this is provided, either as part of the repository or elsewhere in a collection of references. It makes more sense in terms of user friendliness to be able to initialise minimalist versions of objects as and when required, and to go back later and fill in the details, it's less disruptive to workflow. Maybe even to add a 'todo' item to a list in the process of creating the object, one that reminds you to do that 'fill-in-the-details', 'house-keeping' task later on. But there is still the issue of mandatory properties preventing an instance from being persisted if they have been flagged as not-null at the database level and not initialised or given default values, a database data validation issue creeping into the object model. In a relational database its an all-or-nothing transaction based approach, in an OO model its nearly always initialisation followed by mutation, different paradigms. So that indicates to me that Isis should provide a solution rather than avoiding it as too complicated, which seems to be your argument. Surely its just a case of delaying persistence until an object is valid (according to the database schema)? Suggestions of using workflows is relevant, but its breaking away from the Naked Objects approach, adding extra work to set it up. Breaking a big object into smaller ones is not solving the issue, for example if you say a client must have an address to be valid, the address can be a separate object but if its a null reference then the client is invalid and if its an reference to an invalid address then you've pushed the problem from the client object to its address object failing to persist. Cheers Steve Cameron On Fri, Jun 5, 2015 at 11:00 PM, Dan Haywood <[email protected]> wrote: > 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 <[email protected]> > 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 >
