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