The name that does the accept/present is the value of `name`, the
`implementation` value is the internal representation type.
So with:
<node name="foo">
<attribute name="x" type="boolean" ...>
you are meant to be able to say:
foo.acceptAttribute('x', "false");
and the system knows that 'x' has a type of 'boolean' so it looks up the
'boolean' type, and calls (effectively):
foo.setAttribute('x', lz.PresentationTypes['boolean'].accept("false"));
to convert the string representation "false" into the Boolean implementation
`false`.
Perhaps a more compelling example would be for the type `color`, which knows
how to parse lots of different color representations, it's declaration would be:
<type name="color" implementation="Number">
...
</type>
<attribute name="bgcolor" type="color" />
You can say:
foo.acceptAttribute('bgcolor', "red");
foo.acceptAttribute('bgcolor', "#FF0000");
foo.acceptAttribute('bgcolor', "rgb(100%,0,0)");
foo.acceptAttribute('bgcolor', "hsv(0,100%,100%)");
and they all mean the same thing.
On 2010-07-15, at 15:46, Henry Minsky wrote:
> 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]
