Yeah we already have the value being interpreted implicitly with the builtin types,so that string type doesn't need need be quoted, etc
<attribute type="string" name="foo" value="bar"/> so it seems natural to make value use the 'accept' mechanism On Thu, Aug 19, 2010 at 4:46 PM, P T Withington <[email protected]> wrote: > Push comes to shove in this case: > > <attribute name="whatever" type="color" style="color" value="black" /> > > Here we have an attribute that is styleable using CSS, which may specify a > value in a number of ways: named color, #format, rgb(), hsv(), etc. It's > pretty clear (to me at least) that the fallback/default specified in `value` > should be in that same space. I should _not_ have to say `value="0"` to > specify a default color of black. > > Therefore, I propose, at least for attributes that have a `style` property, > the `value` property is assigned to the attribute using the specified type's > `accept` method. > > On 2010-08-11, at 11:44, P T Withington wrote: > > > Here's an important question that needs answering, before we can really > go anywhere with this: > > > > If I define a new type, say `trilean`, that is stored as 0, 1, or 2, but > is meant to represent a tri-state yes/no/maybe button in a form, when I > write: > > > > <attribute name="again" type="trilean" value="???" /> > > > > What is the expectation about the `value` field? > > > > Currently, for all the built-in presentation types, (except for color), > `value` is interpreted as the corresponding Javascript type, but maybe this > is just luck because the Javascript type and the LZX type look similar > enough no one noticed. E.g., I say: > > > > <attribute name="ok" type="boolean" value="false" /> > > > > I use the Javascript value `false`, not the representation `"false"` > (which is how a boolean would be stored in a dataset). > > > > If we extend that model, for my trilean, I would have to write: > > > > <attribute name="again" type="trilean" value="2" /> > > > > which is not really helpful. I would have to remember wether `2` > corresponds to "yes", "no", or "maybe". I would much rather write: > > > > <attribute name="again" type="trilean" value="maybe" /> > > > > Is this what people expect? I'm not sure how we could reconcile the > current built-in types with this new distinction. It makes me think that we > need a new property of attribute that is the "representation type"? > > > > <attribute name="again" type="trilean" ???="maybe" /> > > > > What's a good name for that? > > > > [that leaves open the issue of how I write Javascript code to manipulate > `this.again` -- there I need to know the corresponding values. Probably I > want to be able to say: > > > > if (this.again == lz.trilean.yes) ... > > > > or something.] > > > > > > > -- Henry Minsky Software Architect [email protected]
