Hi Dan See my inline comments
On Thu, Jun 11, 2015 at 4:29 PM, Dan Haywood <[email protected]> wrote: > On 11 June 2015 at 01:32, Stephen Cameron <[email protected]> > wrote: > > > > > 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. > > > > > Not sure I agree with this; the constraints in the database are derived > from the domain constraints. Or said another way, we do the domain > modelling, then derive the persistence model from it. > > > Sure, that is not what I was meaning, instead its the all-or-nothing nature of an SQL insert versus the create and then mutate nature of OO programming. A database rejecting an insert is an error creaping up into the OO layer, not something that is of interest to a user, as they cannot do anything about it. > > > 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)? > > > > > If I rephrase this into an argument I do agree is valid... why does Isis > require that an object has to become valid within a single HTTP > request/user interaction; why cannot Isis "look after" a not-yet-valid > object over a number of requests until it becomes valid? > > That, I would say, is a legitimate question, and as explained before > earlier versions of Isis used to do something like this (albeit in a > limited way) but does not any longer. The issue we have found is that it's > not enough to consider a single not-yet-valid object; what inevitably > happens is that we end up with a graph of > not-yet-valid-and-so-still-transient objects, and maintaining all that > state outside a db quickly becomes a nightmare. > Yes, I can see your point! > > Right now view models are our preferred way in which we let you maintain an > arbitrary graph of stuff that's being worked on. If that seems like to > much overhead,then another idea is to have "scratch" domain entities that > are similar (perhaps even identical) to the original entity to be > persisted, but with relaxed constraints such that they can be persisted. > When they become properly valid, they could be removed and replaced by > proper entities. > This is actually what i was thinking might be possible, but to use serialized objects or XML versions, put these into a file or table 'buffer' and update with each mutation, in case the application stops, before the fully valid object can be persisted. Its interesting for me to contrast this with the XForms model, where validation is the principle issue and complex validation rules can be defined, and where form submission is prevented until the 'model' is fully valid. > > > > > 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. > > > > > I do think it is *part* of the solution... a smaller object is more likely > to be valid than a larger one because it will have fewer constraints. This > may mean changing the way the business users operate, doing smaller > incremental steps. But if ultimately it's the responsibility of a business > person to ensure that all these constraints are valid, then breaking out > that problem into a set of smaller problems is probably A Good Thing (TM). > > OK, I need to try this for myself, even if relationship is 1:1, its the OO way. > ~~~ > This discussion is all somewhat theoretical... which I like, by the way, > it's great to discuss these things ... but I also want to say that we try > to use real-world use cases as the way to drive out the development of > Isis, rather than pure theory. If you hit a modelling issue that cannot be > solved with Isis as it is, we should use that as a way to help us decide > what new feature might be needed. > Looks like I will get to do this small project so I will have the chance to hit some real-world issues. :) I showed the demo today and it got a good response. In general I can see there is alot to like about Isis as is. Also, in no way do I see Isis as a CRUD only framework, in fact I have kind of given up on OO frameworks for CRUD ("Where things have gone off the rails in recent years is that we’ve confused object-oriented code designs with data entity designs." says Ron Hitchens in 'Your Object Model Sucks' http://overstory.co.uk/whitepapers/YourObjectModelSucksPragPub.pdf ) so its the behavioural aspect of DDD and Isis that I am most interested to explore. > Thanks again for the conversation > > My pleasure, I highly value your book and the Naked Objects book, so the chance to contribute to Isis is important. Sadly, I have had great problems making money from my interests, which has almost led to me giving up on IT frankly. It might interest you that I briefly worked for Centrelink. Centerlink is the part of the Australian Federal Department of Human Services. When I was there I learned that they used a mainframe that was one of two still in production worldwide, this is just about to be replaced finally at enormous cost. > Cheers > Dan > > > > > > > > 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 > > > > > >
