I think we'd use a standard json parser/unparser. And yes, you can add your own types!
----- Reply message ----- From: "Raju Bitter" <[email protected]> To: "P T Withington" <[email protected]> Cc: "Max Carlson" <[email protected]>, "Henry Q Minsky" <[email protected]>, <[email protected]>, "OpenLaszlo Developers" <[email protected]>, "OpenLaszlo Users" <[email protected]>, "Norman Klein" <[email protected]> Subject: [Laszlo-dev] <attribute> types and values: explanation and question Date: Tue, Dec 14, 2010 3:49 pm How would more complex data types (like JSON structures) work with this approach? Would there be a default API to define custom behavior for converting the string value into structures? On Wed, Dec 15, 2010 at 12:32 AM, P T Withington <[email protected]> wrote: > `stylevalue` (or whatever we come up with) would have all the same power as > `value`, so yes, it can be constrained. The motivation was for being able to > set an attribute to an hsv value. I could have said: > > <attribute ... value="${lz.ColorUtils.internalfromhsv(computeh(), > computes(), computev())" ... > > I'd like to be able to say: > > <attribute ... stylevalue="${'h(' + computeh() + ', ' + computes() + ', ' + > computev() + ')'}" ... > > And yes, it would be an error to have both. > > On 2010-12-14, at 17:39, Max Carlson wrote: > >> I like stylevalue, but maybe defaultvalue is more descriptive? Can I make a >> constraint on a stylevalue? I assume having both value and stylevalue would >> be an error? >> >> ----- Reply message ----- >> From: "P T Withington" <[email protected]> >> To: "Max Carlson" <[email protected]>, "Henry Q Minsky" >> <[email protected]>, "André Bargull" <[email protected]>, "Norman >> Klein" <[email protected]> >> Cc: "OpenLaszlo Developers" <[email protected]>, "OpenLaszlo Users" >> <[email protected]> >> Subject: <attribute> types and values: explanation and question >> Date: Tue, Dec 14, 2010 2:00 pm >> >> >> + 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. >> > > >
