I recently fixed some issues around the event boxes in the calendar views (see calendar-multiday-view.xml and calendar-view-core.xml). They are implemented by means of XBL and although they are certainly a very sophisticated use case I found that the implemented bindings do not always utilize all features of this markup language. Probably some of these features are also missing in many other bindings around the world and so I thought this is worth a blog entry :)
Basically an XBL binding contains several elements: One ‘content’ element where the structure of the binding is defined, one ‘implementation’ element, that controls the behavior and one ‘handlers’ element that listens to events.
For the maintenance of an arbitrary XBL binding it is imperative to keep as much information as possible within its ‘content’ element. This way it is far easier for the developer to perceive the structure and logic of the binding and it also helps to avoid redundant information that may lead to bugs during the development process. If the developer should decide to modify the structure of a binding binding he will most likely run into problems when he then has to adjust the ‘implementation’ code at many places, too. In this context the ‘attribute inheritance’ feature executed by the ‘xbl:inherits’ attribute proves to be very helpful. This
attribute takes care that modifications are forwarded down to the appropriate child elements. When it is done like this, attributes may be directly set at the binding without any internal knowledge about it.
In some cases anonymous elements were added unnecessarily to the bindings. For example quite often one box element can be removed just by extending a binding to a ‘xul:box’ or whatever. ‘Spacer’ elements may be exchanged by setting the ‘pack’ or ‘align’ attribute to the parental element.
I observed that there is also some redundancy in the code. I remember that this has not been resolved with regards to the possible performance loss. From all I have read and heard about XBL this argument is to be taken seriously, but I believe that the use of the ‘children’ tag within a binding could be an elegant solution, because it allows to add various anonymous content at a defined insertion point.
XBL goes hand in hand with cascading stylesheets – whereupon one should pay close attention to move all style settings to ‘.css’ files. In my struggle with the calendar views I was frequently confronted with completely unexpected problems and side effects caused by seemingly harmless style attributes. For example I could see that setting attributes at certain elements seem to force a distinctive relayout and consequently trash the whole view because of too many other ‘compact’ widgets involved. This and some other side-effects have made me occasionally become anxious to destroy the layout by merely looking at the .css files!
Last but not least I certainly don’t get around to admit that the views have always run quite reliable and offer a vast functionality with an appealing design! As we all know a lot of blood, sweat and tears have accompanied their implementation…
I hope that we will find some time to give the code its finishing touch at the beginning of the next release cycle so that we have time to react to the inescapable regressions that will come up.