On Mon, 19 Jul 2010, Greg Brown wrote:
I think one way to approach this goal is to consider BXML as a sort of
intermediate language---an input to a serializer that builds a
component hierarchy. You could keep that completely clean as a sort of
souped-up javabean serialization format, hell, even cleaner than it is
now.
If you want to generate an intermediate hierarchy, you can do that in
any number of ways: XML DOM, JSON, or even BXML - but you'll face the
same performance issue as with your CSS approach: it requires walking
the tree multiple times. BXML allows you to construct and populate the
tree in a single pass.
On top of BXML would be a DSL that makes some UI-centered assumptions.
It might make some assumptions about the use of some style language,
like CSS, to make it easier to work with. It might use CSS inheritence
and cascading. It might allow closer integration with scripting
(*cough PIVOT-573 ahem*) and richer event-driven binding support.
All of these things are already supported. Even PIVOT-573 could be
easily supported if we wanted to. The DSLs are defined by the beans
themselves - for example, the reason JSON can be used in a "styles"
attribute is because Component#setStyles(String) is coded to parse JSON.
Any bean class can define its own DSL using a similar approach.
There is a lot of crap in MXML. I'm not holding it up as an example of
greatness, but at the same time it does have some very useful,
time-saving features, some of which I noted above.
Can you provide some specific examples of things that MXML does that
BXML/WTK does not? Clearly some features were missing prior to Pivot
2.0:
- default properties
- dynamic data binding
- stylesheet support
However, all of these features have since been added. What other aspects
of MXML would you like to see added to BXML?
Simple support for listening for custom bubbling events. In my current
implementation, it looks like
Events.listeners="{ eventName1: 'eventListenerName1', eventName2:
'eventListenerName2' }"
which isn't horrible but it's a lot more verbose than
eventName1="eventListenerName1" eventName2="eventListenerName2"
Also, being able to bind to arbitrary properties on suitably annotated
objects would be very helpful as that is the primary means for model
objects like domain objects to notify its listeners in general but its
views and validators in particular of its changes. I'm "working" on an
implementation of that. Don't know when I will "finish" it.
Can't think of anything else off the top of my head, but if I do you know
you will hear from me! :)
Michael
