Chronicle of the Xul Revolution
|
|
|
Chronicle of the Xul Revolution |
In the new Luxor Titan Interview series I will interview the movers and shakers of the Luxor world. To kick off the series let's all welcome R. Dale Asberry.
Q: Can you tell us a little bit about yourself?
R. Dale Asberry: I started programming in 1979 and began doing it professionally in 1989. Languages I've programmed in include C++, SQLWindows(Centura), Delphi, Visual Basic, and, of course, Java. I attended my first JavaOne in 2000 where I saw the "Implementing JiniTM Connection Technology Within the U.S. Army's 21st Century Battlefield" and was absolutely amazed. The coolest Jini system I've built was a MMPOG platform capable of adapting to varying performance loads and dynamically recovering from failure.
Q: How did you stumble onto the Luxor XUL toolkit? Have you tried out any alternative XML UI language alternatives before settling on Luxor?
R. Dale Asberry: After having used tools like SQLWindows, Delphi, and VB, writing Java GUI apps just felt "wrong". I kept my eye out for toolkits that might eliminate the clunky, brittle Java code. I eventually stumbled across Mozilla XUL but felt uncomfortable requiring users to have Mozilla installed. I think I Googled something like "XML user interface" and found Luxor. I followed the links on the Luxor site to the other toolkits but felt that the other projects didn't provide me with enough details to get a "Hello World" app going in 15 minutes. The Luxor project was well documented and seemed to have the most features implemented.
Q: How did you get started on Installer DeLux?
R. Dale Asberry: One of my personal principles is "It just Works". My first non-employer work was the Judy project at Jini.org. One of the difficulties with Jini is that it's difficult to get up and running Out-of-the-Box. I decided that including an installer for Judy would greatly enhance the "It just Works" idea. As for why I created Installer DeLux (I'm working on a blog entry for this), I wasn't happy with the open source or freely available installers.
Q: Can you tell us some challenges you faced building Installer DeLux using Luxor?
R. Dale Asberry: Some of the typical open source project difficulties: manual configuration (instead of automatic installation), rich but non-exhaustive featue set, minor documentation bugs, that sort of thing. One thing about the tool itself is that OOTB, it requires a Java programmer to do a bit of wiring in his own program to connect the various Luxor bits. I've encapsulated those things using reflection, properties, aspects, and a very lightweight framework so that an installer writer doesn't need to do any manual wiring unless she is intentionally extending the functionality.
Q: How did you stumble onto AspectJ?
R. Dale Asberry: I think it was an article on IBM developerWorks or some other such site. I thought the concepts would allow it to elegantly address the most annoying OO deficiency - cross-cutting dependencies. I started playing around with a pre-1.0 release and decided that it was too early to use it. I felt the 1.1 release was ready for prime time and I started learning it in-depth.
Q: Can you tell us what aspects and cross-cutting concerns you can see in Luxor?
R. Dale Asberry: I classify aspects into two types: functional and connective. Functional aspects capture intra-class crosscutting concerns while connective aspects capture inter-class concerns. I've only started to look at the Luxor codebase in detail so I haven't seen any "big picture" types of concerns yet.
Q: You're a well-known Jini master. Can you tell us what role XUL may play in the Jini world?
R. Dale Asberry: One of the first Jini standards to be accepted was the ServiceUI spec. It allows a remote client to query the service's available GUI interfaces to match the client's needs. However, a client doesn't get an instantiated GUI from the service, it gets a service factory. This very flexible mechanism lets any client use any type of Java-based GUI. I think that Luxor would be an excellent fit for any kind of downloaded user interface.
Q: Do you have a favorite scripting language for the Java runtime? Do you want to see scripting pushed more in Luxor?
R. Dale Asberry: My favorite scripting language is BeanShell. Groovy is starting look interesting, but I'm not ready to accept it as my own scripting language yet. I've not yet used scripting with Luxor so I'm not sure how the two things fit together.
Q: What do you think is still missing badly in Luxor?
R. Dale Asberry: Acceptance - using Java programming is a plain bad approach for manipulating user interfaces. As for the tool itself, it would be nice to have the loose ends I mentioned earlier cleaned up.
Q: What's next for Installer DeLux?
R. Dale Asberry: It's still very incomplete. I need to finish the core functionality, as well as, improve the project documentation. Long term, I plan on developing a commercial graphical installer builder on top of the base installer.
Q: What are your future plans for Luxor?
R. Dale Asberry: I've just started a Luxor sub-project to refactor Luxor using aspects. I'm hoping that this will make Luxor more maintainable over the long run. I'm also looking to contribute a more GUI controller that eliminates the "wiring" code, however, the code I currently have is too specific to Installer DeLux.
That's it. Thanks R. Dale Asberry.
No one is going to clone Avalon, in 6 months, or 3 years even. It is a huge complex API. What you see here is a marketing angle, to take advantage of a buzzword, and push your product. I am sure that true xaml will never run correctly on Xamlon -- but "xaml" sounds great, doesn't it?
- Frank Hileman
Source: xaml-talk Yahoo! Group
Please comment your rating. Use the comments box below. Thanks.
Due to popular demand I've started an eXtensible Application Markup Language (XAML) only mailinglist over at Yahoo! Groups.
I invite you to sign up and help the discussion get going. The postings so far include:
Please comment your rating. Use the comments box below. Thanks.
Please comment your rating. Use the comments box below. Thanks.
Andy Oliver (of Apache POI fame and now JBoss employee/consultant) has written up a blog story titled "XUL dreams" that outlines the architecture for a new JBoss console using XUL.
Andy writes:
I'd be happy to have *technical* feedback from XUL experts or other ideas to make this better. Please keep technology evangelism to a minimum. I'm interested in:
So here are my nearly free-flowing thoughts so far. For the server side of this console I envision this...
Don't keep Andy hanging and share your thoughts on the next gen JBoss console architecture here or on Andy's blog or join the discussion on the xul-talk mailinglist.
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 |
