> -----Original Message----- > From: Alex Harui [mailto:aha...@adobe.com] > > I think Tigran wants to know where the allowed set of attributes for a tag > come from. They come from the set of public variables and setters on the > class represented by the tag. To add "automationName", you would add it > to UIBase.as (and UIBase.js) > > However, it is my goal that things like automation is packagable as a plug-in > (bead) and thus instead of changing UIBase.as, you would create a separate > bead (like maybe call it UIBaseAutomation.as and UIBaseAutomation.js and > build a similar tree of subclasses for existing components), and the > developer would add such beads to the components as needed. That way, > components that are re-used as "internal" do not have to carry slots for > optional properties, and code not needed in production is easier to not > initialize and run. > > Then the MXML would look like > > <basic:CheckBox> > <basic:beads> > <basic:CheckBoxAutomation automationName="foo" /> > ... > > -Alex
Alex, I understand what you say. So, basically there is no goal to try to keep the MXML format compatible, right? If there is no such goal then perhaps we do not need to support legacy properties like automationName. I am not sure it is needed at all when one can make sure the 'id' property is set to a meaningful and descriptive value. I cannot see a valid use case when one would want to have a 'name' for automation purposes that is different from the 'id'. If one is concerned with developing an automation friendly app just make sure to set the 'id' properties. Actually the only reason why I thought supporting 'automationName' property is good idea is because it could be already specified in existing MXML files. However if those MXML files are not going to be compiled by FalconJX without modification I see no point in supporting 'automationName'. I will stop pursuing this further unless there are other opinions on the subject. Tigran.
