pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "aappddeevv" <aappdde...@verizon.net>
Subject RE: BXML
Date Wed, 04 Aug 2010 01:37:27 GMT
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.


Mime
View raw message