Dynamic MXML tags in Flex 3.0. Please?

This one is on the top of my list of “the most wanted” for Flex 3.0. I am tired of the treatment MXML gets from us coders. In ActionScript classes you can make class “dynamic” and add properties at will. There is no similar construct on MXML.

Here is what I think would work and be very “natural”. If you use a MXML tag derived from “dynamic” (actionscript) class, MXML should allow unknown attributes – without a warning. To force type information on the unknown attributes developers can use {binding} notation – we are misusing it for initialization anyway, so it would be quite natural.

I would also argue in favor of “dynamic” or “expando” attribute on every control for application developers (changing a hat). A lot of “business layer frameworking” could have been avoided if each object would expose a single “Object” property you can add your props to. That would allow application “polymorphism” in a dynamic way that is different to tachings of pure programming science but greatly simplifes application coding.

Here are examples of cumbersome code that would greatly simplified (no need for extra classes, simplier syntax, etc.) by the above approach:

http://samples.faratasystems.com/AdvancedDataGrid/index.html – there is complete source there – PropertyBagDemo is a good example of “dynamic” approach. By the way, thanks everyone for the emails on this one!

Thank you,


4 thoughts on “Dynamic MXML tags in Flex 3.0. Please?

  1. I agree, with some smart naming convention you could keep the compiletime errors of class variables and a precedding symbol on the dynamic means you would never get the two confused.

  2. Anatole — dynamic properties work today in Flex 2.0. Mark a class dynamic, and you can add whatever attributes/child tags you want to its tag in MXML.

    Regarding your second request…I agree with the value of the request, and would love to add it in F3 (which is not the same thing as saying it will be in F3…those are sadly very often two different things). It has to be added carefully though…hitting the right balance where instances can be easily decorated, without losing the benefits of strong typing, is a delicate thing.

  3. Ely,
    Ouch, I feel so ashamed – I thought I tried it (could of been beta) and now it works!!! Very cool.

    As far as strong typing we misuse binding with <tag expando=”{true}” – may be different syntax would make it look cleaner and let developers distinguish initialization from binding/rid all the binding warnings.

    Thank you,

Comments are closed.