But what about the short-form of defining an <attribute>'s value, that
means to define the value as an attribute on the instance? Adding just
another attribute on <attribute> won't help for this case.
Otherwise you'd be forced to use the more verbose form by using
<attribute> all over the place. So instead of:
<view background="hsv(...)" />
You'd need to use:
<view>
<attribute name="background" stylevalue="hsv(...)"/>
</view>
And that for each and every <attribute> with a presentation type. IMO,
this doesn't look very user-friendly.
On top of that, if a new attribute is added, it should contain only very
few keystrokes (I surely don't want to write overlong names over and
over again!). `stylevalue` or the other alternatives so far are quite
long (two words for each!). My take for a new attribute name to denote a
default value: `default`. For sure `default` is really concise and by
that possibly confusing to have both, `value` and `default`, for
<attribute>. But is it more confusing than `value` together with
`stylevalue` (or one of the others: `typevalue`, `styledefault`,
`typedefault`, `presentationvalue`, `stringvalue`, `defaultvalue`)? The
difference between `value` and the new attribute needs to be explained
anyways, so it shouldn't be such a big deal to explain `value` and its
difference to `default`.
Concerning the issue described at the beginning of this mail, so
<attribute> definitions on instances. We could add a constraint-like
syntax for this case, for example:
<view background="#{'hsv(...)'}"/>
This would get compiled into:
<view background="${`background`.type.accept('hsv(...')}"
On 12/14/2010 11:00 PM, P T Withington wrote:
+ 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.
