Nice write up! Can that go on the web site? I can only provide these personal thoughts:
I think the discussions around BXML here really are just saying, hey, there is an original BXML use-case that it satisfies fair enough to your point. But it could do more and that may make pivot have a competitive edge against other frameworks. Also, by writing it a bit more pluggable instead of hard-coded in some places, you can pick up most other use cases anyway and reduce code complexity nicely for the entire application not just in the pivot library. I think its been well proven that intercepting (even a little) the creation and initialization of an object hierarchy (the wiring) can be a huge complexity reducer. That's what spring's container does. A few small idioms from DI containers would make BXML stand out from MXML and XAML even more. I don't believe in taking it so far that a strength becomes a weakness though and I don't think the current serializer is that far off from what I would like to see. I would rather see some other structural pivot issues addressed. Personally, I am thinking of maintaining my own version, based on the current, and dropping scripting. I do not have a background in "documents" and web programming so while I can see BXML's roots there, I don't look at it that way at all. I found scripting to be a complexity that is not needed and anything that is not specified in XML greatly increases the cost of toolability. However, the changes I already made to the serializer and personally maintain are small enough that its not worth it at this point. A BXML compiler is not out of the question given aspectj and ITDs actually although it is unclear what the performance benefit would be. I think its critical that you, as a pivot-library-person, do consider the library expense of simplicity and maintainability from the pivot library perspective. However, I consider those factors from the entire app perspective so my lens is a little different. Neither point of view is right or wrong, its just a choice of where the line is drawn. Fortunately, its open source so the line can be moved around if people feel strongly enough about it and want to maintain their own version. I would definitely post a snippet of your comments on the web site as it's a good expression of core design intent. Is there a wiki for pivot? -----Original Message----- From: Greg Brown [mailto:[email protected]] Sent: Tuesday, August 03, 2010 10:48 AM To: Pivot Dev Subject: BXML Since there has been some continued discussion about it, I want to clarify what BXML is and what it is not: - BXML is an XML-based markup language for simplifying the construction of an object hierarchy (often a WTK component hierarchy). - Unlike some other similar markup langauges (e.g. MXML and XAML), BXML is not compiled into a Java class. It is a serialized representation of an object hierarchy (though it may optionally include embedded or externally-referenced script code). - BXML is processed using the StAX API defined in the javax.xml.stream pacakge. This is a stream-based API that processes XML elements and attributes in the order in which they are written. - Element and attribute ordering is relevant in BXML: - In an element's start tag, the corresponding class is instantiated. - As sub-elements are processed, they are either added to the element or applied as properties. - In the element's end tag, the attributes are applied. This is because certain attributes will not make sense until the element has been fully constructed. - If the element's parent is a sequence, the object is added to the parent. BXML is simply a shortcut to coding this logic by hand. - BXML supports the declaration of page-level variables via the bxml:id attribute or in script code. These variables can be dereferenced elsewhere in the page using the "$" operator. As in procedural code, variables must be declared before they are referenced. The only exception is namespace bindings, which are not processed until the entire document has been processed. This is because namespace bindings are a shortcut to wiring up event listeners, which is generally done after a page has been completely loaded and all required variables have been initialized. - Root elements that implement Bindable will be called to initialize() once the BXML document has been completely processed. This allows the Bindable to get access to the document's namespace (i.e. page variables), the resources that were used to load it, and the location it was loaded from, to perform any necessary post-processing (e.g. registering event listeners). Only the root element is initialized, because the bindable properties (namespace, resources, and location) apply to the document as a whole, not to individual sub-elements. I'm sure there are lots of other things that BXML could do, but which may come at the expense of simplicity and maintainability. The current implementation may not address absolutely every use case, but it does address the primary use cases quite well. Doing anything else would be over-designing it.
