Welcome back to the Xul Titan Interview series. Today let's welcome MyXaml mastermind Marc Clifton.

Q: Can you tell us a little bit about youself (short bio)?

Marc Clifton: I’m living in Rhode Island with my son and lovely girlfriend, while finding that most of my clients seem to be in San Diego, California! After a few successes and many failures in my 20’s, and working in such diverse fields as video games, edutainment, voter registration, videometric analysis and remote sensing, satellite design and adult entertainment (no, not as an entertainer, but as a software engineer), I have come to love the idea of process automation and all that is involved in learning about a business process and streamlining/automating it. I’ve adopted the techniques that I developed working with my clients to my own business — the business of writing software. The unique clients that I work with require a software foundation that allows for both early prototyping and late stage redesign. From this need was born the Application Automation Layer. The AAL predates, not the concept, but the widespread acceptance (mania?) of XML. After a few false starts in re-implementing the AAL within the context of XML, I have settled on MyXaml as the next great cornerstone to the AAL.

Q: How did you stumble onto XAML? Have you tried out any alternative XML UI language alternatives before?

Marc Clifton: I tend not to be an early adopter of new technologies unless they fit within my work style. Probably to a fault, I don’t usually even bother to keep up with the latest nifty features from Microsoft that won’t have a real impact on my life for many more years. As a result, I literally didn’t have a clue about XAML until I posted the first article on what became the foundations for MyXaml. A reader posted a comment, something along the lines of “have you heard of XAML?” Ummm. Nope. Prior to that, I hadn’t tried out any alternative XML UI languages either. I already had my AAL framework in place and it was quite successfully handling a diverse set of needs. While not XML-based, the UI definitions, data modeling, and workflow was all scripted, so while it didn’t “look” like XML, it “felt” the same.

Q: How did you get started on MyXaml?

Marc Clifton: Well, as I mentioned, I already was using a scripting framework that I developed myself. As I made the migration from C++ to C#, I started to take on a few XSD/XML issues. I really like the concept of a schema definition (because I reminds me of a database programming), but I was surprised that there weren’t any programs (that I could find) that took an XSD and generated an XML editor dynamically from the XSD. So I first wrote a simple XSD editor to learn about XSD and then I wrote a simple dynamic XML GUI generator.

My original attempt to convert the AAL to an XML-style scripted framework was OK, but not great. One day I woke up realizing that you could parse an XML file and use reflection to obtain type information to instantiate classes, and then set property values based on the attributes of the XML. This “ah ha” experience came about while I was putting together a complete XSD editor for a client and I was utilizing reflection and property setters/getters to avoid writing a factory for each Xml… class in Microsoft’s SOM. I think it was that work that got me to see the light. Even so, my first implementation of what became MyXaml was awkward.

Q: Can you tell us some challenges and design choices you faced building MyXaml?

Marc Clifton: One of the first challenges was: what do I do about Microsoft and Avalon/XAML? Well, that was an easy decision—-ignore them! The bigger picture that I have for MyXaml makes what Microsoft is doing seem like something from the stone ages. As I delved into some of the Avalon-XAML design, I can definitely say that I do not regret the “ignore them” decision one bit.

I also grappled with the issue of how generic the parser should really be. It’s very easy to slip into the “oh, I’ll just write some custom parsing for this requirement” mode. The problem is, not every namespace has XAML friendly classes. It became clear that for the parser to stay generic, it needed a standard method for instantiating non-compliant classes. I liked this approach because the parser could remain faithful to its karma, as it were, while add-ons could deal with reformulating an obstinate class into something the parser liked, or simply take over the parsing for a while.

The reader comments (especially from “leppie”) were really helpful in cleaning up some ugly design (due to my ignorance). As some use cases started evolving, the design decision to work within the confines of an existing namespace/class architecture really began to solidify. I began ripping out what custom parsing there was in MyXaml and replacing it with more generic, well-formed classes. The result, if I may be so humble, is very elegant, and is demonstrated by being able to take Frank’s vector graphics engine and being able to instantiate and manipulate objects without a single change to the MyXaml parser (*cough* except for fixing a few bugs and adding some missing implementation!). The result is demonstrated in a beautiful vector graphics animated clock. Compare the XML for this clock to the one mentioned in the article created for Avalon-XAML. To me at least, the MyXaml version is much cleaner (thanks to Frank’s excellent VG architecture!)

Q: What's the hook? Why would anyone use MyXaml over say good old C# coding?

Marc Clifton: That’s a tough question. The problem is, a lot of people don’t care what the underlying code is because they’re working at the form designer level. Quite a few people have said they have no interest in touching Avalon’s XAML, and they better not have to! They expect the form designer and wizards to hide all the gory details. But there are a few people who are using MyXaml that need dynamic runtime form creation, and it’s easier to generate XML than it is to generate C# code.

But the hook for me is the decoupling of the user interface from the presentation layer. We often talk about these two concepts as if they are the same, and they really aren’t. The user interface is, in my thinking, the controls and OS “backplane”. The presentation layer is the application specific management of the UI—its state and any data translation needed between the business objects and the OS’s representation.

But the real hook for me is to abstract this one step further—MyXaml is, by its very nature, an Interpreter Pattern, Builder Pattern, and lightweight Mediator Pattern. It promotes the complete decoupling of objects while at the same time providing a system that is highly adaptable to changing requirements. This is exactly what the original AAL succeeded at doing. Using MyXaml with an event manager in a model-view-controller architecture is an incredibly powerful technique.

Q: Can you tell us some challenges you faced building your MyXaml Visual Designer using MyXaml?

Marc Clifton: Well, the challenges are yet to come! The technology preview version was something my friend Gary originally wrote in straight C#. Basically, it took the Divil form designer and the syntax editor from www.actiprosoftware.com, and presto, a lightweight MyXaml designer. But then I thought, this thing ought to really have MyXaml as the front-end, otherwise people are going to laugh at me! So I reworked the designer host to make it more XAML friendly and re-wrote the front end in MyXaml. Took all of about three days. Of course, I wanted to make sure that the markup couldn’t be changed, so it’s been digitally signed with a couple signature tests implemented in the supporting assembly.

However, serializing/deserializing from/to the designer host isn’t easy. I want the markup to look clean, and a generic serializer would spew out a lot of unnecessary information. For example, if I serialize out Size, Width and Height values are redundant! Deserialization presented some problems to, especially when recursing into child controls. The original code wasn’t very friendly to the idea of regenerating the form, which took a bit of rework.

And as I said, the challenges are yet to come—plug in capability, handling controls like menus, etc. .NET has a lot of custom collection objects as well (for example, StatusBar, ComboBox, ListBox, and CheckedListBox each have their own collection object) which result in a lot of custom handlers. You really discover the flaws in an object model when start working with serialization!

The most interesting challenges deal with integrating a complex application consisting of multiple namespaces, local objects, in-line/out-of-line/code-behind code, events, and resources, teasing apart these pieces so that they can be easily managed, integrating them back in for the final markup, and at the same time allowing the user to edit the markup directly. There are some non-trivial issues here!

Thanks Marc Clifton. Check back next week for the second part of the XUL Titan interview with Marc Clifton discussing styling (XML vs. CSS), scripting, MyXaml for free .Net runtimes such as Mono or DotGNU or alternative UI toolkits such as Gtk#, wxNet, Qt# and much much more.

Links:

• MyXaml Project @ http://myxaml.com
• MyXaml Forum @ http://myxaml.com/forum
• Marc Clifton's Blog @ http://myxaml.com/marcclifton
• Marc Clifton's Code Project Article Line-Up (51 and counting)