incubator-isis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Matthews <>
Subject Re: Why are NonPersistent field not editable?
Date Mon, 11 Oct 2010 11:51:31 GMT
Here is the essential code

public class SetupPlanName extends PlanRelatedJob implements JobPrompt {

     // {{ name
     @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) {
         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.


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

View raw message