Flex SDK Wiki

# Shorthand Syntax for Parameterized Layouts **Closed 8/22/2008** ## Merits of providing shorthand for the Group layout property Until recently, Gumbo layouts could only be specified by naming a layout class, like this: <group layout="flex.layout.VerticalLayout"> your column of items here ... </group> The type of the Group layout property was Class and the MXML compiler handles this special case by mapping the property value string to Class object. The actual ILayout instance is private to Group and is initialized by calling the layout class constructor with no arguments. This approach complicates configuring layout classes, since one would have to create subclasses whose null-constructors configured the layout appropriately. To remedy this, the type of the Group layout property has been changed to Object and the implementation deals with mapping from a String to Class to an instance at runtime. In other words existing code still works but one can also write: <group> <layout> <verticallayout gap="4" rowcount="7" rowheght="20"> </verticallayout></layout> your column of items here ... </group> Because we're now mapping from a String to a Class at runtime, one must ensure that an explicit dependency on the specified Class exists. Otherwise it will not be linked into the executable. Presently, the three existing Gumbo layouts are unconditionally linked this way. All of this leads to the following question. Should we continue to provide a shorthand for specifying layout? ### Pros * Nice for hand coding. Experienced developers tend to enjoy even the smallest conveniences. * Improves MXML document readability for developers who are familiar with the syntax. * Increases the likelihood that the subelements in an MXML document will only correspond to the GUI hierarchy. This helps highlight what's essential. ### Cons * Diminishes MXML document readability for casual developers. * Tools burden: tools must preserve the short/long form of the layout property. Changes to the layout value may force tools to replace the original short form, which developers might find confusing. * Similarly, developers may feel needless gravitational pull from the short form. * The simple compiler extension that supports class lookup is unlikely to be satisfactory in general. A general purpose shorthand syntax is likely to just recapitulate XML. Custom shorthand syntaxes per type small like macro preprocessing. ### Additional Discussion The Flex SDK ARB discussed this issue at some length on 8/22/2008. Although it was decided that shorthand for the layout attribute wasn't essential for now, the general question about the merits of supporting a generic shorthand syntax for object values remains open. My notes from the discussion follow. More material on this topic can be found in TBD-link-to-shorthand-doc. Flex3 already supports a special micro syntax so that one can specify left,right,top,bottom relative to a ConstraintRow,Column. More about that here: [http://labs.adobe.com/wiki/index.php/Flex_3:Feature_Introductions:_Enhanced_Constraints](http://labs.adobe.com/wiki/index.php/Flex_3%3AFeature_Introductions%3A_Enhanced_Constraints) There's also existing special syntax in Flex4 for qualifying attribute values by state: [http://opensource.adobe.com/wiki/display/flexsdk/Enhanced%20States%20Syntax](http://opensource.adobe.com/wiki/display/flexsdk/Enhanced%2BStates%2BSyntax) We could provide custom compiler support for stringClassName-or-Value properties. This would be adequate for supporting the existing layout syntax. Zuckerman: could the value of a property be RHS AS code to be evaluated once? Not data binding, just code, like "new VerticalLayout()". This would be difficult for tools, since it's impossible to update arbitrary code. Since this is already possible by binding, perhaps the compiler could optimize away the binding linkage in cases where it could determine that evaluating the RHS once was sufficient. Even specifying just class name (as we're doing now) implies that the tool would have to replace the shorthand with the long if the developer reconfigures the layout. Language features (generic shorthand) are very costly for Thermo. A special case for layout would be less so. Utility classes like VBox,HBox with a facade for the layout object would mitigate the pain of having an explicit layout subelement. "Attached" properties like "layout-gap" on the Group could be looked up by the Group's layout. In other words the layout could configure itself by binding to Group properties. New issue: should we provide HBox,VBox, etc. Further discussion: is longhand sufficient, pros and cons of specific short-hand syntaxes.