MDrivenText

This is the proposed new ViewModel data textual representation.

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

How the Format looks:

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 of when 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 the 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 the 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 makes heavy use of commas as seperators - 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 whereas 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 the 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.