Simple 'Scoping' Problem

Hi Ishan,

if I understand correctly, you want to restrict the property to two allowed values. This can be done in Constraints

concepts constraints Foo {
  can be child <none>
   
  can be root <none>
   
  can be parent <none>
   
  can be ancestor <none>
   
   
  property {p1}
    get:<default>
    set:<default>
    is valid:(propertyValue, node)->boolean {
      propertyValue :eq: "Optional" || propertyValue :eq: "Mandatory";
    }
...
}

Additionally you want to offer the two values in a code-completion menu invoked on the editor cell belonging to the property. For this you have to do two things:
1. mark the editor cell as right-transform target:
Style:      
<no base style> {         
  << ... >>
}           
            
Common:     
cell id <default>         
action map <default>      
keymap <default>           
menu menu parts:           
     apply side transforms
        side: right        
        tag: none         
attracts focus noAttraction
show if <no condition>     

2. Define a side-transform

side transform actions PropertyValues   
           
           
right transformed node: Foo tag: default_  //<no description>         
  condition :            
    <none>
           
  common initializer :   
    <no common variables>
    ....................................
    <no common initializer>              
           
  actions :
    add custom items  (output concept: Foo)            
      simple item         
        matching text     
          Optional        
        description text  
          <default>      
        icon node         
          <default>      
        type              
          <default>      
        do transform      
          (model, operationContext, sourceNode, pattern, editorContext)->node<> {
              sourceNode.p1 = "Optional";
              sourceNode;
}
           
   

---

    add custom items  (output concept: Foo)            
      simple item         
        matching text     
          Mandatory      
        description text  
          <default>      
        icon node         
          <default>      
        type              
          <default>      
        do transform      
          (model, operationContext, sourceNode, pattern, editorContext)->node<> {
              sourceNode.p1 = "Mandatory";
              sourceNode;
}
        
Please check the attached project for a quick sample.   

Depending on the use-case, a more generic and extensible approach would probably be to define separate concepts to represent Mandatory and Optional, both inheriting from a common abstract concept "P1Kind_whatever" and having "p1" to be child of cardinality 1 of type "P1Kind_whatever".
This way language extensions could provide their own kinds, for example. Also, instead of string comparison when checking the type of "p1" you could call virtual behavior methods defined on "P1Kind_whatever" in a polymorphic way.

Hey,
Thanks for the solution.
I wanted to know the difference between the above method and creating a enumerated datatype for the property.
Also once the user chooses one of the property value, he is allowed to edit it. This should not happen.

Also, when I add constraints to the property, I want the user to get a personalized error instead of the default error in the tooltip.


Thanks.

Hey,
Thanks for the suggestion. But in my project i have many concepts with many properties with multiple values feasible. So to define concept for each and every property value would be a tedious task. So is there any simpler solution?

Thanks.

Hey can you attach a sample project depicting this behavior. I am not able to understand it properly.
Thanks

Sure - here it is.

As for editing, both approaches allow for the "editable" property to be set to "false" down in the inspector window on the particular editor cell.

The error messages for Constraints violations cannot be customized. The type-system checking rules can, however.