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.