|
|
Re: A CSS Engine for Swing
|
Posted: Jul 23, 2008 4:31 PM
|
|
My initial reaction was, "Finally, someone who wants to completely get rid of *.properties files!" Yet, I'm not sure CSS is the right approach. It's familiar, though, and people tend to prefer things that they trust instead of preferring things that are of high quality. Unless a developer is trained to know what to look for in a DSL, they will invariably choose a DSL that looks familiar to them.
Currently, I am developing a Silverlight 2 application. Through no choice of my own, I am using XAML. Being forced to use a language has a strange way of forcing you to become an insider and assess the language fairly. Initially, I did not like XAML at all. After using it for three months, it has become familiar and -- surprise -- is now my preferred template language. Funny how adoption works.
The question I've been asking myself is, "Was it just a matter of becoming familiar with the language that changed my opinion about it?" I don't think so. I still see major problems with the way Microsoft expects developers to write XAML. My two biggest complaints are that XAML out-of-the-box violates the Open-Closed Principle and promotes Pollution of the Knowledge Space.
For instance, if I want to adjust the style of a column header for a DataGrid control, then I have to copy-and-paste a multiple line ControlTemplate off MSDN and edit one line within that ControlTemplate. All I want to do is adjust a Layout Property like VerticalContentAlignment, yet the out-of-the-box way of writing XAML forces me to pollute the Style setter with information unrelated to Layout Properties. In doing so, I have polluted the knowledge space by providing excess details to accomplish the primary objective of the Style setter. These extraneous details are orthogonal concerns that I should not have to worry about at that particular point in time.
From what I have seen on the Internet, most criticism of XAML is an ad hominem attack against Microsoft. For instance, they argue that we already have XForms, CSS, XHTML, XUL, SVG and sXBL. From their perspective, it looks like Microsoft is re-inventing the wheel and that XAML is just another weapon for an Embrace, Extend, Extinguish coup d’état. Such a point of view is sad, but a reflection of the fact that Microsoft has continuously changed the standard way of doing things. For synchronization, it used to be Hailstorm and now it is LiveMesh. For database technologies, it has evolved from ODBC to OLE DB to RDO to ADO to ADO.NET. For any given technology Microsoft has touched, there has been disruptive evolution.
Yet, in XAML, Microsoft appears to have created something permanent. It is a single, unified language that closely obeys Elliotte Rusty Harold's stringent Effective XML guidelines. The biggest negative is that it is tightly coupled to the CLR; the Application Pack URI format is just one example of its tight integration with Microsoft virtual machine technology.
So my thoughts lately have been, "If XAML is here to stay, how can I make it more pleasant to work with such that I am not violating the open-closed principle and promoting pollution of the knowledge space?" This is where attempts like Nicholas' Swing CSS engine might be able to teach me something useful, even if the answer is, "This is a mistake. Don't do the same thing in XAML."
|
|
Previous Topic
