You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Tigran Najaryan <ti...@gmail.com> on 2013/04/23 08:32:22 UTC
[FalconJX] trying to add support for more MXML properties
I am trying to understand how to make FalconJX compile extra MXML properties
such as automationName.
The current FalconJX compiler throws an exception
java.lang.IllegalAccessError when the MXML file it compiles contains an
unknown property.
Can someone please tell me where does the processing of the properties take
place? Looking at the source code it looks like the compiler uses class
definitions for property parsing (is the processing of MXML properties done
in MXMLComponentNode.processTagSpecificAttribute?).
I have not been able to identify where does the class definition information
come from and how to modify it to include new properties, so I'd appreciate
a few hints.
There is also a need to add appropriate error processing so that the
compiler outputs proper error message when the MXML file contains
unsupported property instead of crashing.
Thanks,
Tigran.
Re: [FalconJX] trying to add support for more MXML properties
Posted by Alex Harui <ah...@adobe.com>.
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" <ti...@gmail.com> wrote:
>> -----Original Message-----
>> From: Alex Harui [mailto:aharui@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
RE: [FalconJX] trying to add support for more MXML properties
Posted by Tigran Najaryan <ti...@gmail.com>.
> -----Original Message-----
> From: Alex Harui [mailto:aharui@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.
Re: [FalconJX] trying to add support for more MXML properties
Posted by Alex Harui <ah...@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
On 4/23/13 1:21 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> In short: compiler.jx (FalconJX) gets it's information from compiler
> (Falcon). The AS/MXML source is compiled for use in compiler.jx by the
> compiler (duh ;-)) into an AST (Abstract Syntax Table), which becomes
> available to use in the JS production in 'MXMLBlockWalker.java ::
> visitCompilationUnit (151)' or, when running the tests, 'TestBase.java
> :: compile (201)'. This AST consists of 'nodes' that are filtered
> through a switch (i.e. MXMLNodeSwitch) that directs the parsing to a
> specific 'visitor' for each type. Mostly all the visitor does is pass
> the node through to a method that takes care of the actual emitting
> (i.e. MXMLEmitter :: emitClass).
>
> You can find the currently 'available' MXML node types in the
> 'compiler :: org.apache.flex.compiler.tree.mxml' package. The
> (incomplete) list FalconJX uses is in 'compiler.jx ::
> org.apache.flex.compiler.internal.visitor.mxml.MXMLNodeSwitch.java'.
>
> HTH,
>
> EdB
>
>
>
> On Tue, Apr 23, 2013 at 8:51 AM, Tigran Najaryan <ti...@gmail.com> wrote:
>>> From: Erik de Bruin [mailto:erik@ixsoftware.nl]
>>>
>>> You mean the property is unknown to FalconJX (i.e. isn't handled yet), or
>> do
>>> you mean a property that isn't part of the "MXML specification"
>>> (whatever that may be ;-))?
>>>
>>> EdB
>>
>> Well, I tried property "automationName" which is part of the current public
>> Flex MXML specification. I do not know if it is also part of "MXML
>> specification" as used by FalconJX.
>>
>> I am actually trying to understand where does FalconJX take this
>> "specification" from. Quick debugging shows that it tries to look up
>> property name in some map however I have not been able to identify where
>> does this map come from yet. If anyone know where should I look for it will
>> speed me up otherwise I am back to examining the source code and debugging.
>>
>> Thanks
>> Tigran.
>>
>
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJX] trying to add support for more MXML properties
Posted by Erik de Bruin <er...@ixsoftware.nl>.
In short: compiler.jx (FalconJX) gets it's information from compiler
(Falcon). The AS/MXML source is compiled for use in compiler.jx by the
compiler (duh ;-)) into an AST (Abstract Syntax Table), which becomes
available to use in the JS production in 'MXMLBlockWalker.java ::
visitCompilationUnit (151)' or, when running the tests, 'TestBase.java
:: compile (201)'. This AST consists of 'nodes' that are filtered
through a switch (i.e. MXMLNodeSwitch) that directs the parsing to a
specific 'visitor' for each type. Mostly all the visitor does is pass
the node through to a method that takes care of the actual emitting
(i.e. MXMLEmitter :: emitClass).
You can find the currently 'available' MXML node types in the
'compiler :: org.apache.flex.compiler.tree.mxml' package. The
(incomplete) list FalconJX uses is in 'compiler.jx ::
org.apache.flex.compiler.internal.visitor.mxml.MXMLNodeSwitch.java'.
HTH,
EdB
On Tue, Apr 23, 2013 at 8:51 AM, Tigran Najaryan <ti...@gmail.com> wrote:
>> From: Erik de Bruin [mailto:erik@ixsoftware.nl]
>>
>> You mean the property is unknown to FalconJX (i.e. isn't handled yet), or
> do
>> you mean a property that isn't part of the "MXML specification"
>> (whatever that may be ;-))?
>>
>> EdB
>
> Well, I tried property "automationName" which is part of the current public
> Flex MXML specification. I do not know if it is also part of "MXML
> specification" as used by FalconJX.
>
> I am actually trying to understand where does FalconJX take this
> "specification" from. Quick debugging shows that it tries to look up
> property name in some map however I have not been able to identify where
> does this map come from yet. If anyone know where should I look for it will
> speed me up otherwise I am back to examining the source code and debugging.
>
> Thanks
> Tigran.
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
RE: [FalconJX] trying to add support for more MXML properties
Posted by Tigran Najaryan <ti...@gmail.com>.
> From: Erik de Bruin [mailto:erik@ixsoftware.nl]
>
> You mean the property is unknown to FalconJX (i.e. isn't handled yet), or
do
> you mean a property that isn't part of the "MXML specification"
> (whatever that may be ;-))?
>
> EdB
Well, I tried property "automationName" which is part of the current public
Flex MXML specification. I do not know if it is also part of "MXML
specification" as used by FalconJX.
I am actually trying to understand where does FalconJX take this
"specification" from. Quick debugging shows that it tries to look up
property name in some map however I have not been able to identify where
does this map come from yet. If anyone know where should I look for it will
speed me up otherwise I am back to examining the source code and debugging.
Thanks
Tigran.
Re: [FalconJX] trying to add support for more MXML properties
Posted by Erik de Bruin <er...@ixsoftware.nl>.
You mean the property is unknown to FalconJX (i.e. isn't handled yet),
or do you mean a property that isn't part of the "MXML specification"
(whatever that may be ;-))?
EdB
On Tue, Apr 23, 2013 at 8:32 AM, Tigran Najaryan <ti...@gmail.com> wrote:
> I am trying to understand how to make FalconJX compile extra MXML properties
> such as automationName.
>
> The current FalconJX compiler throws an exception
> java.lang.IllegalAccessError when the MXML file it compiles contains an
> unknown property.
>
> Can someone please tell me where does the processing of the properties take
> place? Looking at the source code it looks like the compiler uses class
> definitions for property parsing (is the processing of MXML properties done
> in MXMLComponentNode.processTagSpecificAttribute?).
>
> I have not been able to identify where does the class definition information
> come from and how to modify it to include new properties, so I'd appreciate
> a few hints.
>
> There is also a need to add appropriate error processing so that the
> compiler outputs proper error message when the MXML file contains
> unsupported property instead of crashing.
>
> Thanks,
> Tigran.
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl