This project is read-only.

Questions about manual

May 18, 2013 at 4:28 PM
Edited May 18, 2013 at 4:29 PM
How would it be possible to get into the scenario described in section

Should (ProgramPersistableOnly) not also be recommended for

Is 3.5.2 not contradictory to and

------------------- From the manual -------------------

The recommended approach is, if possible, not to permit the user to create a new transient object that is a child of an existing transient object, but, rather, to require the user to save the parent object first. This can be done by marking-up actions that create child objects with Disabled(WhenTo.UntilPersisted). ProgramPersistableOnly

This attribute, when applied at class level, indicates that transient instances of a class may only be persisted programmatically - not directly by the user. This is typically used where you wish to create one transient object within another transient object (sometimes referred to as the 'aggregation' pattern) and you do not wish the user to be able to persist the child object separately from the parent object. By marking the child object with the ProgramPersistableOnly attribute the user cannot persist it directly (hitting the Save button while that object is transient confirms the edits but does not persist the object). However assuming that the Parent object holds a reference to that Child object, then the child will be persisted automatically when the parent is persisted.

In the stateless mode of operation, transient objects do not exist on the server between user actions - they are automatically re-created using the values posted from the page. This means that it is not possible to associate multiple transient objects, so, for example, you will typically have to persist a SalesOrderHeader before creating and associating any SalesOrderDetails with it.
May 20, 2013 at 9:57 AM
Valid question. ProgramPersistableOnly goes back to earlier versions of the NOF (e.g. the 'WPF' user interface), where the user could have a transient object that contains one or more other transient objects (e.g. an OrderHeader with one or more OrderDetails) - and a major headache for us was objects getting saved in the wrong order.

With Naked Objects MVC , I think this scenario could arise if you had 'store transients on session' set to true (which is not a pattern we encourage, and is not liked by most web architects) - but not otherwise.

I will raise a ticket to review the documentation on this and/or consider whether ProgramPersistableOnly could/should be obsoleted. Meantime, if you are not storing transients on the session it is not a scenario you need worry about.