> The current code does not handle listener code in BXML. > These restriction may be removed if someone who know BXML well. > But for me, some JS based BXML file translated in Java uisng JS interpreter > seems not so appealing situation. > Why do we want to use JS in Java?
It is sometimes convenient to use JS. Also, it allows us to execute code that is not compiled (for example, in BXML that is generated by a server or an authoring tool). Finally, you are not restricted to JS - you can use any JVM scripting language, such as Groovy or Clojure. > So I have not tried much for supporting this aspect. I don't think that will be a problem. If you are converting BXML to Java, you probably don't want to use script anyways. You may however still want to define event/handler mappings in BXML, such that Java methods will be invoked instead of script functions - I have been prototyping a way to make this easier and will be sharing the results soon. > Also in order to support this style of code generation, some of the final > class definition must be changed in Pivot. These classes are final by design. Making them final allows them to be treated more like "structs" in JVMs that support advanced escape analysis. They are not meant to be instantiated or manipulated in BXML (though you can use them in script). > and some handling of attribute evaluation order is desirable. As I mentioned in my previous email, attribute ordering is only relevant if the generated code is meant to be human-readable (which I do not see as a priority). G
