# or @ are both good choices. I use a German keyboard, but I set the
keyboard mapping to English when coding. []{} are difficult to reach
on German keyboards.On Wed, Dec 15, 2010 at 8:36 PM, André Bargull <[email protected]> wrote: > > > On 12/15/2010 6:10 PM, P T Withington wrote: >> >> 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? > > latex uses # for argument, xpath uses @ for attribute axis selector, css > uses # for id-selector, java uses @ for annotations, and so forth. There is > no consistent use for both characters, neither @ nor #. > > Some examples to prove #{...} is actually used in different programming > languages: JSF expression language [1], prototype template engine [2], ruby > interpolation [3] etc. A similar list can be given for @{...}, see [4,5]. > > Comparing the various keyboard layouts on [6], I don't see any evidence that > `#` is harder to type. `...@` is actually harder to type on German keyboard > layouts - so you know why I'd prefer `#`! ;-) > > > [1] > http://developers.sun.com/docs/jscreator/help/jsp-jsfel/jsf_expression_language_intro.html > [2] http://www.prototypejs.org/api/template > [3] > http://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Literals#Interpolation > [4] http://www.google.com/codesearch?q=[";']%23{[^}]%2B}["'] > [5] http://www.google.com/codesearch?q=[";']%40{[^}]%2B}["'] > [6] http://en.wikipedia.org/wiki/Keyboard_layout > >> >> <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. >>>> >>>> >> >> >
