create new object with mandaory properties, best method

[Stephen Cameron <st...@gmail.com>]

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, then when you access
the new object later on, its via another form, its 'own' bigger form

So its seems to me that all object creation requirest two forms one to
create an object and another to maintain it. 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.

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?

Perhaps I need to understand object lifecycle better?

Thanks
Steve Cameron

Re: create new object with mandaory properties, best method

[Stephen Cameron <st...@gmail.com>]

Hi Dan

See my inline comments

On Thu, Jun 11, 2015 at 4:29 PM, Dan Haywood <da...@haywood-associates.co.uk>
wrote:

> On 11 June 2015 at 01:32, Stephen Cameron <st...@gmail.com>
> 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 <
> dan@haywood-associates.co.uk
> > >
> > 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 <st...@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
> > >
> >
>

Re: create new object with mandaory properties, best method

[Dan Haywood <da...@haywood-associates.co.uk>]

On 11 June 2015 at 01:32, Stephen Cameron <st...@gmail.com>
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.



> 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.

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.



> 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).

~~~
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.

Thanks again for the conversation

Cheers
Dan






> Cheers
> Steve Cameron
>
>
>
>
>
> On Fri, Jun 5, 2015 at 11:00 PM, Dan Haywood <dan@haywood-associates.co.uk
> >
> 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 <st...@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
> >
>

Re: create new object with mandaory properties, best method

[Stephen Cameron <st...@gmail.com>]

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 <da...@haywood-associates.co.uk>
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 <st...@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
>

Re: create new object with mandaory properties, best method

[Dan Haywood <da...@haywood-associates.co.uk>]

On 6 June 2015 at 23:56, Stephen Cameron <st...@gmail.com> wrote:

> Thanks for the detailed response Dan, I will study and come back with
> thoughts.


sure, please do.



> What I am building will be open-sourced so I will try to document
> the issues encountered and choices made.


I look forward to seeing more than that.

Cheers
Dan

Re: create new object with mandaory properties, best method

[Stephen Cameron <st...@gmail.com>]

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 <da...@haywood-associates.co.uk>
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 <st...@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
>

Re: create new object with mandaory properties, best method

[Dan Haywood <da...@haywood-associates.co.uk>]

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 <st...@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