Proposed new ViewModel data textual representation.

Goals: Text based modeling, more to-the-point, less bloated, easier to write format than json (specially true if you consider attribute values that in turn are strings that may have special chars like ',",{ etc )

How does the format look:

viewmodel ValueOfFirstColumn{  
  column NameOfAColumn{ValueOfThatColumn}  
  column NameOfAColumn1{ValueOfThatColumn}  
  column NameOfAColumn2{ValueOfThatColumn}  
  column NameOfAColumn3{ValueOfThatColumn}  
  nesting ValueOfFirstColumnOfNestedObject{    
    column NameOfAColumn{ValueOfThatColumn}  
    column NameOfAColumn1{ValueOfThatColumn}  
    column NameOfAColumn2{ValueOfThatColumn}  
    column NameOfAColumn3{ValueOfThatColumn}  
    }  
    
  nesting ValueOfFirstColumnOfNestedObject{    
    column NameOfAColumn{ValueOfThatColumn}  
    column NameOfAColumn1{ValueOfThatColumn}  
    column NameOfAColumn2{ValueOfThatColumn}  
    column NameOfAColumn3{ValueOfThatColumn}  
    }  
}  

An Example if the ViewModel is named "class", has a nesting "attribute" and another nesting "role"

class Thing{  
  SuperClass{SomeSuper}  
  attribute Attribute1{    Type{string}  }  
  role Detail2{  
    Cardinality{0..*}    
    TargetType{Detail}      
    BackName{Thing2}
    BackCardinality{0..1}
    Aggregation{composite}
    IsNavigable{true}
    RoleClass{TheRoleClass}  } 
}

Definition of format

classifier+space+Key{ ===content===}

The ===content=== is defined as: [classifier+space+]Key{===content===}

Every key must be unique in its list

Format treat multi or single relation the same - and to a certain extent even attributes

A list property can be set in 2 ways; classifier+space+key{} repeated with unique keys , or nameoflist{key1{} key2{} key3{}} (explicit form)

Why have classifiers and not always use explicit form : easier on the eye to read - resembles c#.

What are classifiers : The definition of the target structure is a ViewModel, ViewModelName and NestingNames corresponds to classifiers.

How does the format differ from json?

• - json has "" on identifiers MDrivenText does not

• - json make heavy use of comma as seperator - MDrivenText does not
• - json handles arrays differently than properties with [ enclosures, MDrivenText derives this knowledge from context
• - MDrivenText has special meaning ViewModel/Nesting classifier separate from other properties
• - json must handle mulltilinks as arrays - MDrivenText collects keys based in Nesting classifier to build lists
• - MDrivenText only has three language fixed elements the {}, space and double quot - the first build structure - the second separates definitions - the third is standard string enclosure. All other characters are part of content

What are the use-cases?

Initially it will be used in MDrivenDesigner to provide textbased editing of classes, statemachines, viewmodels and actions. This in turn will be the initial format when experimenting with other ways (than MDrivenDesigner) to change the model

How will the format be implemented - is this a new transformation?

We will use TajSon functionality and route all logic through the TajSon Mechanisms

Plans are to allow for a generic editable textual representation of any viewmodel.