I like the idea of "#{'hsv(...)'}" as the way to indicate that the value is a
presentation type value, not a Javascript value. But let's think about what
the right character is to represent that:
# -- makes me think 'number', sh uses for comment, C for directive, HTML for
anchor
@ -- makes me think 'at' or 'address of' or 'per', C# uses for verbatim
strings, Objective C uses for string literal
There are plenty of other choices, but the connotations above make me lean
toward `...@`. Also, I think `#` is hard to type on non-US keyboards?
<view background="@{'hsv(...)'}" />
But it is still a lot of characters to type.
Another idea: If we restrict this feature to styled attributes, the shorthand
format could be:
<view style="background: hsv(...)" />
and as a constraint we could allow:
<view style="background: ${'hsv(...)'}" />
Although that will take a bunch more magic in the compiler.
Comments?
On 2010-12-14, at 20:17, André Bargull wrote:
> 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.
>>
>>
