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" />
   </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

There's also existing special syntax in Flex4 for qualifying attribute values by state:
http://opensource.adobe.com/wiki/display/flexsdk/Enhanced%20States%20Syntax

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.