> OK, I'm not actually thinking BXML should be abandoned. There are many type > of user and usage scenario which would fit BXML approach. > But these approach is static, it is not good fit for creating more dynamic > library for GUI(for instance the number of table columns are changed based on > passed parameter class). > Since you put low priority for supporting readable Java code generation, I > thought you may not be interested in this type of approach.
I don't see the value in trying to generate "readable" Java code from BXML. If you are a developer who prefers to declare your UI in Java (perhaps using your builder approach), then you probably won't be using BXML anyways and won't care what the generated code looks like. If you are a developer who prefers BXML, you most likely will never look at the generated code, since presumably you want to continue developing in BXML and only use the compiler for the performance or compile-time type safety benefits. Besides, all we're really talking about here is where generated attribute setters go. The generated code would still be quite readable - it just may not be organized exactly the way you would do it had you written it by hand. To me, that's just not a major issue.
