[Laszlo-dev] Thoughts on extending LZX types

[Sarah Allen]

I think I'm missing a little context here... if you have some xml like
<foo a="1" b="true" c="1/18/09/">
how does a type declaration explain that b is a boolean and c is a date?

Sarah

On Feb 9, 2009, at 12:41 PM, P T Withington wrote:

> We've had some internal discussions on this.  This summarizes my  
> thoughts.  Input from the community would be welcome.
>
> We have 3 type systems in LZX:  1) XML types, 2) Javascript types,  
> 3) presentation types.  XML types are defined by XML, but we have  
> extended them.  The XML types define how the tag-compiler parses/ 
> evaluates/defaults attribute values into the Javascript types used  
> by the runtime.  They all have a corresponding Javascript type,  
> which is how the value is represented in Javascript, and we have  
> recently added (internally to the LFC) the concept of a  
> "presentation type", that defines how an XML/Javascript type is  
> mapped to/from a string representation in a dataset.
>
> I think we can reduce the complexity of this system by integrating  
> XML types and presentation types, making presentation types the  
> mechanism whereby one can define new XML types in LZX.  Presentation  
> types can codify the algorithms for the tag-compiler to parse  
> attribute values into their Javascript representation.
>
> We would like to extend presentation types in two ways:
>
> 1) To become the mechanism for defining new LZX types.  For  
> instance, for the built-in type boolean:
>
> <type name="boolean" jstype="Boolean">
>   <method name="accept" arg="string">
>     switch (string.toLowerCase()) {
>       case "": case "0": case "false":
>         return false;
>       default:
>         return true;
>     }
>   </method>
>   <method name="present" arg="value">
>     return (!! value)? "true" : "false";
>   </method>
> </type>
>
> Or adding a new type date:
>
> <type name="date" jstype="Date">
>  <method name="accept" arg="string">
>    return new Date(Date.parse(string));
>  </method>
>  <method name="present" arg="date">
>    return date.toString();
>  </method>
> </type>
>
> This defines the LZX type `date` which is represented in JS as a  
> `Date` object.
>
> 2) to map XML/Javascript types to/from components (simple example:  
> map to a text-edit component and use the existing string mapping;  
> more complex: define protocols for presentation-type to component  
> mapping based on type theory, range, dimension, enumerability, etc.)
>
> At a minimum, we would add `validate` and `describe` methods for  
> types, which the component can use to test if an input value is  
> permitted and to create a tooltip or other help to assist the user  
> in entering a correct value.  E.g., we might add to the `date` type:
>
>  <method name="validate" arg="string">
>    return (! isNaN(Date.parse(string)));
>  </method
>  <method name="describe">
>    "A date in UTC format"
>  </method>
>
> There will have to be more methods to interface with more complex  
> components.
>
> ---
>
> As an added benefit, we could use this same mechanism to codify the  
> debugger's interface and allow users to define how the debugger  
> represents types, describes and inspects objects, without having to  
> add methods to the actual type.
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20090209/738ff7ee/attachment.html