I prefer the keyword "recipe". I don't think that 'default' should be overloaded yet again. I like the constraint-like syntax for instances.
I'm all for adding more colorful keywords words when its appropriate and I think it works here. Besides I'm always thinking of what to eat, when I'm coding. Norman On Tue, Dec 14, 2010 at 5:17 PM, André Bargull <[email protected]>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. >> >> >>
