BXML

[Greg Brown <gk...@mac.com>]

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.

Re: BXML

[Greg Brown <gk...@mac.com>]

> Nice write up! Can that go on the web site?

Yes - it will most likely be incorporated into the "BXML Primer" when 2.0 is released.

Re: BXML

[Todd Volkert <tv...@gmail.com>]

> 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.

Well said.  The fact that we each come at this from our own point of
view is one of the biggest strengths of OSS, in my opinion.  As long
as we all stay civil and realize that everyone is just trying to do
what's best from their point of view, we should be able to thrive :-)

-T

Re: BXML

[Greg Brown <gk...@mac.com>]

> 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

FYI, this has recently been revisited - check out the changes in revision #981995. Todd can provide more detail.

RE: BXML

[aappddeevv <aa...@verizon.net>]

That's consistent with my thoughts then. If I look at BXML use generally in
pivot, the BXML trees are not large or complex. I think they are more
complex in XAML where because of their design decision to push as much as
possible into XAML e.g. templates, data binding, triggers, xml extensions
(which I would like to see as pluggable in BXML), the XAML is larger and
more complex. Maybe then the benefit becomes bigger. I can absolutely see
where pre-parsing/compiling templates would save time.

As a side thought, its easy enough to add elements to the current serializer
and maintain or write a new serializer. So that's not my focus for the
moment. Playing with templates and such seems to give a good productivity
boost to writing UIs and customizing.


Meandering...

As a highly controversial set of statements, playing with the template stack
(looks exactly like the WPF stack but in pivot), I had two thoughts:

a) Kind of like it. I still like putting a lot into BXML and its easy to
customize. Templates started in the java web world, were implemented in a
funky fashion by MS, and it seems to work pretty good to have that circle
complete. Reduces the need for skins (a reduction in code to maintain) and
can make styling handling more direct.

b) I think the Component inheritance hierarchy is missing a class. A class
between ConstrainedVisual and Component that handles child management
instead of Component handling child management. I wrote a bunch of
components to use brushes (auto-sizing gradients) and paint some basic
building blocks, like ellipsis and other things. Some of these "content"
items do not need mouse or keyboard handling and have limited semantics.
There are a bunch of objects that would benefit from being in the tree more
directly and should skip the overhead of a Component. They have limited
skins. Instead of Drawing and Canvas, just add a "visual" that draws a nice
rectangle, line or ellipse--reduces BXML noise. The entire set of Decorators
falls into this category as well. Decorators can be wrappers around other
visuals instead of a list applied as they are today. This removes the need
for the Decorator API completely. The paint method would need to paint on
this new class instead of Component. This allows more smaller pieces of
drawings to add up...think of Border being a visual that draws a border and
a label on top that does the label. Today, it is one component but could be
composed of two simpler components to make one component. This introduces
reuse and less code duplication in various places. This capability can be
added without breaking the current API.

No need to respond to this...just thinking out loud.


-----Original Message-----
From: Todd Volkert [mailto:tvolkert@gmail.com] 
Sent: Tuesday, August 03, 2010 2:24 PM
To: dev@pivot.apache.org
Subject: Re: BXML

> 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.

FYI, I prototyped one back in the day, got it working, and the
performance benefit was surprisingly small (maybe a 10-15% gain) given
the resulting code complexity.

Re: BXML

[Todd Volkert <tv...@gmail.com>]

> 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.

FYI, I prototyped one back in the day, got it working, and the
performance benefit was surprisingly small (maybe a 10-15% gain) given
the resulting code complexity.

RE: BXML

[aappddeevv <aa...@verizon.net>]

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:gkbrown@mac.com] 
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.