In your proposed syntax, does the value you specify for "implementation" becomes the classname that implements the accept/present behavior for the type?
On Thu, Jul 15, 2010 at 3:33 PM, P T Withington <[email protected]> wrote: > 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. > -- Henry Minsky Software Architect [email protected]
