Currently, I have no plans to match every one of the properties in the current Flex SDK. Erik has mentioned making the effort to try to do so, but I still think that is too much work and the results will not be as optimal.
Which properties we keep from the current FlexSDK in FlexJS depends on several criteria, such as ease of implementation, performance, how well it maps to JS, and customer demand. If we heard lots of folks insist on having automationName in the base class, I'd probably put in there. Basically, my philosophy is this: If you had 10,000 lines of code in your Flex app and want to port it to HTML/CSS/JS, you can manually re-write all 10,000 lines, or you can re-write a subset of those lines of code and have the rest cross-compiled. Sure it is probably technically possible to not have to re-write any lines and have it work, but I don't think it is practical for Apache Flex to provide that. So, if you need to re-write your UI layer, and therefore no longer use automationName, then that is part of the subset, and most of your other code should cross-compile. I don't know why the Adobe team did not require using "id" and came up with automationName and a bunch of other properties. If those turn out to be useful for QTP automation then we'll probably package that as a bead, but if you don't need it, then it will make your implementation easier for your customers. -Alex On 4/23/13 6:44 AM, "Tigran Najaryan" <tig...@gmail.com> wrote: >> -----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. > > -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
