I fully support your idea, but I've still got some questions for you,
they vary from very simple ones to quite implementation-specific ones. I
just want to make sure we're not going to be too loose in the
specification phase. (Most of them need to be answered at some point in
the implementation process anyway.)
Questions:
- In the current proposal, the `implementation` value seems to be
unused. Is it necessary to have this value at all?
- `implementation` doesn't sound that mnemonic, is there a better name?
- How is <type> mapped to a lzs-class? Does it take the same approach as
the current built-in presentation types, that means a class with two
static methods accept() and present()?
- Can you add additional <method>s and <attribute>s to a <type>?
- Is <type> going to be a top-level element?
- Will it be possible to define types in script?
- accept() and present() aren't typed in your proposal, why did you omit
typing?
- Which attributes / methods are required for <type>, will there be
useful defaults?
- Is it an (compile time) error to refer to a type in <attribute> when
there is no matching <type>?
- Is it an (compile time) error to have two types with the same name?
- Will it be possible to override built-in presentation types?
- Will it be possible to defer loading of presentation types, that means
can you place <type> in <import>ed libraries? (Possible implications
with stricter typing and the as3 runtime?)
- Will you add examples to the dev-guide and other places, so people
will be aware of this new feature?
- What about creating a wiki-page for the proposal, maybe that will make
it easier to amend the proposal in comparison to an e-mail conversion! ;-)
- André
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<ptw at pobox.com
<http://www.openlaszlo.org/mailman/listinfo/laszlo-dev>> 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
/>/ hminsky at laszlosystems.com
<http://www.openlaszlo.org/mailman/listinfo/laszlo-dev>
/
