+ 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.
