Chronicle of the Xul Revolution
|
|
|
Chronicle of the Xul Revolution |
Welcome back to episode II of the Xul Titan Interview with MyXaml mastermind Marc Clifton.
Q: Can you point out how the MyXaml XML styling differs from classic non-XML CSS styling and what's better using an all XML route?
Marc Clifton: To begin with, MyXaml integrates an object’s style in the element declaration because the element’s attributes are used to define the object’s appearance. This is different from having a separate definition for the element style. From that starting point, MyXaml supports styling with two classes--Style and PropertyStyle--which implement styling by setting/overriding property values for elements that include a Style=”someStyle” attribute. One interesting note—because the attributes are processed in order, you can override the style property values by placing the overriding attributes after the Style attribute.
I don’t know if there’s a better or worse—it probably depends more on with which style (hahaha) the programmer is comfortable. For now, styles in MyXaml use XML, and there’s a nice consistency there. I haven’t considered supporting stylesheets and probably won’t for some time to come.
Q: Do you have a favorite scripting language for the .Net common language runtime (CLR)? Any plans for adding support for inline scripting to MyXaml?
Marc Clifton: I don’t have a favorite scripting language, and this poses and interesting problem. To me, a scripting language, while essential for object detangling, should be lightweight—it shouldn’t replace a “deep” language like C++ or C#. By that I mean that things like objects, polymorphism, complex conditionals and loop control, isn’t appropriate in a scripting language. It then becomes like more powerful languages, but stunted, so what’s the point? A scripting language, in my mind, should implement a high level Strategy Pattern—it should allow you to mix low level, generalized algorithms, to produce specific solutions or workflows (this is what the AAL scripting language does). I’m interested in looking at BPEL for some ideas, but I haven’t settled on anything in specific. I will definitely be adding a scripting engine which can plug into MyXaml (but MyXaml will not provide one natively). As it is, “scripting” can currently be done directly in C#--MyXaml will compile and instantiate complete classes at runtime defined in the CDATA block of the XML or implemented as separate files. I’ve written complete applications this way!
Q: Do you have any plans of adding web-style form submission tags to MyXaml? What's your recommended approach for data-binding for MyXaml forms?
Marc Clifton: At some point, I’m going to look at what happens when I instantiate controls in the System.Web.UI namespace instead of System.Windows.Forms. Beyond that, I haven’t decided what direction to go regarding web forms. Generating web-style form tags is an interesting idea, but I probably will stick to getting MyXaml to work within the ASP.NET architecture rather than having MyXaml generate HTML forms.
The approach for data-binding is interesting. .NET already provides a data binding mechanism in the System.Windows.Forms namespace. But it’s annoying—the data transfer doesn’t occur until the user tabs off of the control. What if you want to interact a little more dynamically with the control, for example, updating the PL object for every keypress? So, .NET’s data binding mechanism is too control-centric. What I’ve done with MyXaml (which will be in the 0.95 release) is to make data-binding more container-centric. Under .NET, if you want to have the container updated with the control contents (or vice-versa) when you want to do the update, you have to work directly with the control. Using the classes that are included with MyXaml, you can work instead with the container. This is a much better way to do data binding because working with the container, you have decoupled yourself from the presentation layer implementation.
Q: Have you tried out MyXaml on free .Net runtimes such as Mono or DotGNU? Any plans of supporting alternative UI toolkits such as Gtk#, wxNet or Qt#, for example?
Marc Clifton: No. I’d like to, but I simply don’t have time to do all these fun things. As for supporting alternative UI toolkits, it depends on how XAML-compliant they are—MyXaml may already be able to work with them!
Q: Can you tell us how popular MyXaml is? (e.g. How many downloads? Can you highlight some applications already using MyXaml? etc.)
Marc Clifton: As of this writing, I’ve had 277 downloads of the 0.94 beta, and 305 downloads of the designer. The website averages 60-80 visits per hour (which includes RSS readers, so it’s sort of a pointless statistic) and peaked at 2000 visitors per hour a couple days ago when I made a post to www.osnews.com. The “MyXaml Visual Designer” blog entry matches the “Is Microsoft Bolixing Up MyXaml” 4 articles with the most views, topping 450 per blog entry.
Several people have contacted me regarding licensing the binary version and/or the source code, and I have actually made my first licensed sale! At this point, all I can say about the people already using MyXaml in real life applications is that they all require dynamic GUI generation, some of it based on information coming from a database, and some requirements where the end-user is allowed to change the UI.
And of course, I’m using MyXaml and the designer in my own application development, which means that I get to experience first hand the shortcomings. You should see my “things to do” list!
Q: Can you tell us how MyXaml differs from Microsoft's Longhorn Avalon XAML?
Marc Clifton: Compare what Chris Anderson wrote about Avalon-XAML:
...it is a good observation that XAML is really just a way to persist a set of CLR objects (of course, a specific set of objects with a specific grammar... not to be confused with a general purpose serialization engine... )
with what I’d say about MyXaml:
MyXaml is a way to persist any XAML-friendly object without a specific grammar using a general purpose serialization engine. Non-XAML-friendly objects can be persisted by writing separate plug-in handlers while staying true to a general grammar and general serialization engine.
XAML was designed to be a compromise markup format, that balanced the toolability and readability aspects of a markup.
What I would say about MyXaml is:
MyXaml is designed to provide a markup format without compromising toolability and readability.
The ironic thing is, after numerous discussions with Frank (from VG.net) regarding serializing vector graphics into XML, we realized that Avalon’s XAML degrades both toolability and readability. It degrades toolability because it relies on custom sub-parsers, and readability because the user is presented with an inconsistent markup syntax.
If you need any more convincing, you can read my blog entries on the tricks that Avalon-XAML pulls when parsing the XML:
You can compare the Avalon-XAML butchering of XML to how the XML should really be presented:
So far, I have not come across a good reason to make a mess of things like the Avalon VisualTree implementation (which they admit requires a custom parser). Remember that the markup is probably not going to be the primary vehicle for creating UI’s—a designer will be. The excuse that “we want the markup to be user friendly” doesn’t fly with me. First, the vast majority of users don’t want and don’t care how the UI is serialized. Second, for those that do care, they want a consistent implementation. Compound properties and attached properties are completely unnecessary, as far as I’ve seen. And you can create VisualTree structures that are quite readable, tight, and markup consistent without resorting to custom parsing. The cynic in me says that Avalon’s XAML is “obfuscated” so that cross-platform markup compatibility and generic instantiation is nearly impossible (as in, too costly to implement) and therefore it would be more financially sound to go with a Microsoft run device/browser/OS that implements the parsing. But this also concerns me. While I don’t care much to play the Microsoft Monopoly game, my concern lies more in the fact that if Microsoft changes their custom parsers, that change will result in changes to the markup syntax, which will break existing XAML markup.
I’ve been told that Avalon XAML is still in the design phase and that feedback such as mine is helpful since nothing is set in stone. That’s good, but it also tells me that I wouldn’t even want to attempt to make MyXaml an Avalon-XAML compliant parser, as it appears to still be a moving target.
Q: Can you tell us how MyXaml differs from Microsoft's Windows Forms Markup Language (WFML)?
Marc Clifton: There are some interesting differences. WFML provides a “method” element, allowing you to call a method with zero or one parameters. This is sort of a poor man’s implementation of inline coding, which MyXaml provides as a complete runtime compiled service. The WFML parser uses a “property-dot” notation for dealing with property types that the type converter can’t handle, similar to the Avalon-XAML compound property. Both are completely unnecessary if the parser is implemented correctly. For example, in WFML:
<MenuItem Text="New" >
<property.MenuItems>
<MenuItem Text="Window" Shortcut="CtrlN" />
<MenuItem Text="-" />
<MenuItem Text="Message" />
<MenuItem Text="Post" />
<MenuItem Text="Contact" />
<MenuItem Text="Internet Call" />
</property.MenuItems>
</MenuItem>
The MyXaml version is written:
<MenuItem Text="New" >
<MenuItems>
<MenuItem Text="Window" Shortcut="CtrlN" />
<MenuItem Text="-" />
<MenuItem Text="Message" />
<MenuItem Text="Post" />
<MenuItem Text="Contact" />
<MenuItem Text="Internet Call" />
</MenuItems>
</MenuItem>
One of the most striking differences however is WFML’s “argument” attribute, which allows you to instantiate classes that do not provide a default constructor, passing one and only one argument to the constructor. MyXaml handles this by implementing a generic Adapter Pattern so that non-compliant classes can be adapted to work with MyXaml. At some point, I’d like to look at the issue of instantiating classes that require arguments. .NET’s MethodInfo.Invoke already does all the hard work of finding the method that matches the argument types, so it really shouldn’t be that hard to pass both strings and references to classes already instantiated in the markup. MyXaml also provides a growing collection of useful extensions such as xml data sources, data binding, etc.
Q: Can you tell us why you switched your license from a Berkeley-style license to the GNU General Public License (GPL)? Do you plan to offer commerical "classic" licenses for MyXaml?
Marc Clifton: I decided to change the licensing to GPL because I realized that there were commercial applications to the parser. I’ve invested hundreds of hours in articles, web development (you can see my talents are not in web design!) and of course MyXaml coding, not to mention $100/month for a dedicated server (so much easier to work with), forum software, etc.
It occurred to me that, while I frankly think parsers like this will be a dime-a-dozen and that “profit” is to be made in commercial add-ons like a designer, I also felt that I didn’t just want to give away the code to people developing closed source applications. And you can’t really use MyXaml as a straight parser unless you inline all your code.
The GPL license is a nice compromise between offering something useful to the open source community while at the same time protecting my investment (to the extent that people act honorably, of course). Essentially, MyXaml has matured from what began as a “here’s something fun to play with” to a real product. Ultimately though, it is still just a parser, and that’s why something like this needs to be accompanied with added value—support, customization, and tools.
After lots of going back and forth, I’m currently offering two licenses—one is a license to distribute the binary assembly which you can reference in your own application, and the other is a non-exclusive source code ownership agreement, which gives you permission to modify and include the source code directly in your application. We’ll see how this all comes together over the next couple of months.
Q: What's next for MyXaml and your MyXaml Visual Designer?
Marc Clifton: I’m working on releasing version 1.0 of MyXaml, which will include support for SQL Data Sources, probably a kind of “include” processor tag, corrected documentation, more complete XmlDataSource and Resource support, better style support, etc. There are a few internal things I want to clean up too. For example, the parser is still a bit Form-centric, which needs to be generalized. I’d also like to look at some XML-based scripting solutions. I post to my blog the daily enhancements, if anyone is interested.
As to the designer, I’ll be releasing a more complete free designer that fixes the bugs that people are finding, while at the same time working on a first cut of a commercial designer. The plan for the commercial designer is to add C# code generation, editing, and compilation as well, ultimately allowing the user to edit any one (designer layout, markup, or C#) and have changes reflected (no pun intended) in the other two formats. This way, the user can work in a format that is the most convenient and comfortable for the work that he/she has to do.
However, there is a very long term and encompassing vision for MyXaml, and that is to create a truly visual designer capable of generating stubs for a model-view-controller (MVC) architecture, state and event management, unit testing, data access, etc. What I’m interested in long-term is some serious automation of common (and frequently misunderstood) programming tasks. The Application Automation Layer that I wrote in C++ covers some of these concepts, but not all, and certainly doesn’t have a designer driving all of it. In my updated vision, MyXaml is a cornerstone to that architecture. I put together a very high-level conceptual drawing of what I have in mind. Readers interested in my work in unit testing and unit test patterns can read my article titled "Advanced Unit Test, Part V" that links back to the other four.
That's it. Thanks Marc Clifton.
Links:
|
|
Please send comments on our web pages to our public xul-talk mailinglist or to a member of our web team. | Copyright © 2003, 2004, 2005 Open XUL Alliance |
