I like stylevalue, but maybe defaultvalue is more descriptive? Can I make a constraint on a stylevalue? I assume having both value and stylevalue would be an error?
----- Reply message ----- From: "P T Withington" <[email protected]> To: "Max Carlson" <[email protected]>, "Henry Q Minsky" <[email protected]>, "André Bargull" <[email protected]>, "Norman Klein" <[email protected]> Cc: "OpenLaszlo Developers" <[email protected]>, "OpenLaszlo Users" <[email protected]> Subject: <attribute> types and values: explanation and question Date: Tue, Dec 14, 2010 2:00 pm + Background We have slowly been moving toward creating a richer set of schema types and adding a generalized mechanism for parsing/unparsing type values. We call this system "Presentation Types" (taken from a feature of the same name in Symbolics Dynamic Windows and Dylan DUIM). Basically, for each schema type, we define methods for "accepting" from an external string representation into the internal Javascript value and for "presenting" from an internal Javascript value to an external string representation (this could be extended to additional representations, e.g., json). This system was first applied to solve a nagging issue in data-binding, where attributes that were of type other than string did not behave properly when data-bound. [For instance, data-binding a `boolean` value to `false` would try to assign the string "false" to a Boolean and the implicit Javascript conversion of the non-empty string to Boolean `true`! With the new system, the type parser correctly accepts the string "false" into the internal Boolean `false`.] This system has been extended for CSS styling. All CSS property values are represented as strings. When a CSS selector applies to a node, the attributes corresponding to the applicable properties parse the CSS property value strings into the appropriate attribute type. [For instance, styling an attribute of type `color` to "rgb(255,0,0)" will correctly set the attribute to the internal representation of red (0xff0000).] Recently, we have added the ability for the debugger to understand Presentation Types for attributes that have CSS bindings (we hope to extend it to all attributes eventually). When inspecting an object with an attribute that has a CSS `style` property, the debugger will represent the value of that attribute as it would appear in a <stylesheet> (rather than simply printing out the internal value, which may be inscrutable to the LZX programmer). As an example, an attribute of type color, when inspected will look like: > bgcolor:color red displaying the schema type and the external representation of the value. For developers, they can inspect the external value representation to see the actual value that is stored: > lzx> Debug.inspect(red) > «color value#13| red» { > value: 16711680 > } > «color value#13| red» > lzx> We're pretty sure that `red` is a lot more user-friendly way to display the color than `16711680`. We are trying to compatibly introduce the use of this system throughout OpenLaszlo, as we believe it is a very powerful mechanism. We hope to eventually allow LZX programs to extend the schema type system for custom types that may be needed for particular programs or features. + Question for the audience: Currently, when one defines (or overrides) an attribute, you can specify a default value: <attribute name="bgcolor" style="background-color" value="..." /> In the past, the value `...` was inconsistently handled. For some types (color, css, size), literals were parsed in the compiler to internal representations, but expressions (e.g., constraints) were expected to yield the correct internal value. For some attributes (fgcolor, bgcolor), special setters try to guess whether they are being called with an external representation or internal value and do the right thing. This system is really a jury rig that has evolved over time, and the inconsistency is the source of a lot of mystifying behavior and bugs. I propose that we improve on the current system by introducing a _new_ attribute property `stylevalue` which will _always_ be an external representation and hence always be parsed according to the attribute's type. Thus, if I want to introduce a new type, say `image`, that could be a CSS-style URL or color or gradient, I would be able to say: <attribute name="background" style="background" type="image" stylevalue="linear-gradient(center bottom, rgb(190,123,115) 31%, rgb(228,160,150) 66%, rgb(255,192,180) 83%)" /> I chose the name `stylevalue` for this property, because I think most people will encounter Presentation Types when working with <stylesheet>s and when defining attributes that have a `style` property, indicating they can be styled. Other ideas: `typevalue` (indicating the value is to be parsed by the type), or `styledefault` (indicating the value is the default when there is no applicable style), or, since this feature is not necessarily restricted to stylable attributes, `typedefault` (a combination of the previous). Your comments and ideas solicited.
