We want to add the ability for LZX programmers to define new attribute types, 
beyond the built-in `boolean`, `number`, `string`, etc.

For data-binding, we use the concept of a "presentation type" that knows how to 
"accept" a string-representation of a type value and convert it to the internal 
(Javascript) implementation, and how to "present" the implementation value as a 
string-representation.  This is similar to the concept of serialization or JSON 
representations.  Unlike JSON, we don't require self-typing representations.  
Our representations have an implicit schema.  (I.e., in JSON, you know a value 
is a String because it is represented in quotes.  We implicitly associate a 
type with a representation in data-binding, because the type of the bound 
attribute defines how the representation will be converted.) 

Here's an example of how one might write the existing built-in type boolean:

<type name="boolean" implementation="Boolean">
  <method name="accept" args="string">
    // Be liberal in what you accept...
    switch (string.toLowerCase()) {
      case "": case "0": case "false":
        return false;
      default:
        return true;
    }
  </method>
  <method name="present" args="value">
    // ... strict in what you present
    return (!! value)? "true" : "false";
  </method>
</type>

Basically, a type is initially going to have two methods, `accept` and 
`present`.  We may add more protocol in the future (such as a `validate` method 
that will check if a string represents a valid member of the type, and a 
`describe` method that can be used to prompt for input).

By letting new types be implemented in LZX, we hope to make it easy to 
data-bind more complex types.

Comments and input appreciated.

Reply via email to