Thanks for the detailed response Dan, I will study and come back with thoughts. What I am building will be open-sourced so I will try to document the issues encountered and choices made. I don't imagine that there is anything that hasn't been thought through in detail in Isis, its more a case of changing mental patterns (i.e. retraining programmers) perhaps.
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 >
