[Laszlo-dev] cleaning up the LZX data types

Henry Minsky henry.minsky at gmail.com
Tue Oct 16 08:59:01 PDT 2007


As Tucker pointed out, we really do need to do a rationalizing of the
attribute data types which are supported by the tag compiler.

Up until I removed the RNG base schema, the tag compiler understood
all of these datatypes, many of which should probably have been only allowed
internally, but as implemented they were all exposed so they could be used
when compiling
LZX code.

declared in the Compiler:
    /** Represents the type of an attribute whose type isn't known. */
    public static final Type UNKNOWN_TYPE = newType("unknown");
    /** Represents a String. */
    public static final Type STRING_TYPE = newType("string");
    /** Represents a number. */
    public static final Type NUMBER_TYPE = newType("number");
    /** Represents an XML ID. */
    public static final Type ID_TYPE = newType("ID");
    public static final Type EXPRESSION_TYPE = newType("expression");
    public static final Type REFERENCE_TYPE = newType("reference");
    /** Type of event bodies. */
    public static final Type EVENT_TYPE = newType("script");
    /** Type of attribute setter function */
    public static final Type SETTER_TYPE = newType("setter");
    /** Type of tokens. */
    public static final Type TOKEN_TYPE = newType("token");
    public static final Type COLOR_TYPE = newType("color");
    public static final Type NUMBER_EXPRESSION_TYPE =
newType("numberExpression");
    public static final Type SIZE_EXPRESSION_TYPE =
newType("sizeExpression");
    public static final Type CSS_TYPE = newType("css");
    public static final Type INHERITABLE_BOOLEAN_TYPE =
newType("inheritableBoolean");


Below are a list of mappings which were declared in order to parse
declarations in the lzx.rnc file. Note that
the compiler permitted any of these datatypes were all usable by developers
in their lzx code, maybe they shouldn't have been.

        sRNGtoLPSTypeMap.put("ID",               ID_TYPE);
        sRNGtoLPSTypeMap.put("anyURI",           STRING_TYPE);
        sRNGtoLPSTypeMap.put("boolean",          EXPRESSION_TYPE);
        sRNGtoLPSTypeMap.put("booleanLiteral",   EXPRESSION_TYPE);
        sRNGtoLPSTypeMap.put("inheritableBooleanLiteral",
INHERITABLE_BOOLEAN_TYPE);
        sRNGtoLPSTypeMap.put("color",            COLOR_TYPE);
        sRNGtoLPSTypeMap.put("colorLiteral",     COLOR_TYPE);
        sRNGtoLPSTypeMap.put("css",              CSS_TYPE);
        sRNGtoLPSTypeMap.put("double",           NUMBER_TYPE);
        sRNGtoLPSTypeMap.put("enumeration",      STRING_TYPE);
        sRNGtoLPSTypeMap.put("expression",       EXPRESSION_TYPE);
        sRNGtoLPSTypeMap.put("float",            NUMBER_TYPE);
        sRNGtoLPSTypeMap.put("integer",          NUMBER_TYPE);
        sRNGtoLPSTypeMap.put("number",           NUMBER_TYPE);
        sRNGtoLPSTypeMap.put("numberLiteral",    NUMBER_TYPE);
        sRNGtoLPSTypeMap.put("numberExpression", NUMBER_EXPRESSION_TYPE);
        sRNGtoLPSTypeMap.put("propertyPath",     STRING_TYPE);
        sRNGtoLPSTypeMap.put("reference",        REFERENCE_TYPE);
        sRNGtoLPSTypeMap.put("script",           EVENT_TYPE);
        sRNGtoLPSTypeMap.put("size",             SIZE_EXPRESSION_TYPE);
        sRNGtoLPSTypeMap.put("sizeLiteral",      SIZE_EXPRESSION_TYPE);
        sRNGtoLPSTypeMap.put("sizeExpression",   SIZE_EXPRESSION_TYPE);
        sRNGtoLPSTypeMap.put("string",           STRING_TYPE);
        sRNGtoLPSTypeMap.put("token",            TOKEN_TYPE);
        sRNGtoLPSTypeMap.put("opacity",          NUMBER_TYPE);




Below are the type names which used to be present in the RNG base schema,
that I removed (the 'set difference'
of the two lists above).
This is where the bug report  we just got about the 'size' attribute type no
longer being supported came from.

        sRNGtoLPSTypeMap.put("anyURI",           STRING_TYPE);
        sRNGtoLPSTypeMap.put("booleanLiteral",   EXPRESSION_TYPE);
        sRNGtoLPSTypeMap.put("colorLiteral",     COLOR_TYPE);
        sRNGtoLPSTypeMap.put("double",           NUMBER_TYPE);
        sRNGtoLPSTypeMap.put("enumeration",      STRING_TYPE);
        sRNGtoLPSTypeMap.put("float",            NUMBER_TYPE);
        sRNGtoLPSTypeMap.put("integer",          NUMBER_TYPE);
        sRNGtoLPSTypeMap.put("numberLiteral",    NUMBER_TYPE);
        sRNGtoLPSTypeMap.put("numberExpression", NUMBER_EXPRESSION_TYPE);
        sRNGtoLPSTypeMap.put("propertyPath",     STRING_TYPE);
        sRNGtoLPSTypeMap.put("size",             SIZE_EXPRESSION_TYPE);
        sRNGtoLPSTypeMap.put("sizeLiteral",      SIZE_EXPRESSION_TYPE);
        sRNGtoLPSTypeMap.put("opacity",          NUMBER_TYPE);

I could put these back as undocumented type names for back compatibility.
But the larger question is
are we happy with our list of attribute types, and do we need to rationalize
it. Also, as Tucker pointed out,
for attribute like color or sizeExpression, we ought to have some runtime
support for users setting them,
otherwise you get confusion like people not understanding why
setBGColor('#ff0000') doesn't work, or
setWidth("50%"), at runtime.




-- 
Henry Minsky
Software Architect
hminsky at laszlosystems.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20071016/aed46384/attachment.html


More information about the Laszlo-dev mailing list