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:[email protected]] Sent: Tuesday, August 03, 2010 2:24 PM To: [email protected] 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.
