I think you're right, we should reinstate.
I've raised https://issues.apache.org/jira/browse/ISIS-5.
Dan
On 11/10/2010 12:51, Robert Matthews wrote:
Here is the essential code
public class SetupPlanName extends PlanRelatedJob implements JobPrompt {
// {{ name
@NotPersisted
@MemberOrder(sequence = "1.0")
@DescribedAs("Give each plan a unique name so they can be
distinguished easily.")
public String getPlanName() {
Plan plan = getPlanBeingCreated();
return plan == null ? null : plan.getName();
}
public void setPlanName(final String name) {}
public void modifyPlanName(String name) {
getPlanBeingCreated().setName(name);
log("Changed name to '" + name + "'");
}
// }}
I wrote it this way so that the task could be used multiple times
before it was marked as completed, and each time it would allow the
name to be changed (rather than simply entered anew. The set method
ensures that the field is seen as editable.
It could be written as an action with helpers to get hold of the
current value, but that wouldn't help if there are other fields that
need to be edited at the same time.
Rob
On 11/10/10 12:38, Dan Haywood wrote:
On 11/10/2010 12:30, Robert Matthews wrote:
Dan
What was your rational behind making non-persistent fields
non-editable?
I guess cos I've only used them in the sense of showing derived
information. If it were editable, then modifying the value would
need to have a side-effect of updating some other property on this
object or an associated one. That strikes me as something that ought
to be represented as an action.
For example, I have a Task object that is created to change a Plan's
details. It is coded so that the get and modify method in the Task
delegate to the Plan (there is no need to persist this information
twice).
Could you post the code, so we can debate it? (Since it's something
that also would occur in NO MVC, it might also be helpful to to get
Richard's view).
