Its the most, busiest time of the year...

Well, things have been pretty busy on my end so I have not had much time to experiment with XUL4IE. I have been reading more about XUL and attempting to create sample applications before attempting to do the same for IE. I am beginning to understand the scope of XUL and how much would need to be done to support it on another platform, especially one that may be more of a hack. I am also still concerned with performance lags that using HTCs may create.

I have started applying some of the concepts of XUL and RDF to the server-side in the form of .NET web controls. This is what the original intent of my research was and I may need to reasset that intent. Anyway, no new progress has been made.

New Name Change

The name of this blog has been changed to "XUL4IE" to match the new direction of this blog. I think it will give some direction to the future purpose of these ideas and writings.

Working Sample Now Available

I finally was able to get my current sample available for download. You can view it here...

http://www.d2media.com/xul4ie/xul.asp

Now this link is an ASP page that takes the generic "xul.xul" file and adds the client-side XSLT reference used by IE to render the contents as XUL.

One thing I was not able to do was get this completely working on Firefox (which seems a bit ironic eh?). It seems as soon as I bind elements to an XBL through CSS, those element disappear from the screen. Does anybody have any pointers to explain this behavior? The important thing I guess is that it is beginning to work in IE, which after all is the reason for this blog.

Here is a list of the files in the directory and what they do...

binding.css - handles the binding of the textbox elements to the xul.xbl
xbl.xsl - an XSLT file used internally by the xul.htc to render the XBL file as IE script
xul.asp - a server side component that just adds the client-side XSLT reference for browsers with a user agent containing "MSIE"
xul.css - a cascading stylesheet containing styles used for rendering XUL in IE. This is the basic theme.
xul.js - a basic JavaScript file that repurposes the binding CSS to be used by the new IE HTML elements created by the xul.xsl file.
xul.xbl - a sample XBL used for testing various XBL structures.
xul.xsl - an XSLT file used to transform XUL into basic HTML tags that IE can understand.
xul.xul - the main XUL definition which creates the page layout.

Please note that this is no where near complete. For instance, the transformation only accounts for very basic XUL elements, and not even all of those! There is much work to be done obviously. Let me know if you would be interested in particpating...

XUL For IE Status

So far the challenge to get XUL working under IE is working better than expected. I continue to encounter small challenges and I may have some items working a little in hacker fashion, but I figure a working model may be the best first step. Then I, or others, could work on optimizing the code to be a little more concise and optimized.

I still haven't gotten a web site running for some of these demos, but then again I may want to wait until there is more to show. So far IE is rendering the XUL elements using client-side XSLT. This generates HTML code that mimics XUL user interface components. This XSLT also calls a piece of JavaScript code that adjusts all attached stylesheets to point tag-based CSS rules to class-based ones. Also, the IE-specific stylesheet applies a behavior to all elements.

This HTC works by reading in the parameters from the -moz-binding stylesheet element and parsing out the URL from the ID value. Then, I use client-side XML and XSLT processing to open the file and cache its contents (so I don't need to open it multiple times). Then, I use another XSLT to generate scripts for all the XBL elements. This is run and then I loop through each field, property, method and event and bind these to the current element.

So not only do I have the XUL looking good, but also have some basic properties and events firing as they would in an XUL-enabled browser. This is just a start, but it gives me hope this is possible.

Discovering XUL

I've been quite taken by some research I have done into XUL. I've been working on a company project and wanted to evaluate existing technologies for declaring user interfaces using XML. I have used ASP.NET, JSP Tags, XML/XSLT, Macromedia Flex and our own tag based controls. So far XUL offers some of the best performance and has made interface design very simple.

One thing that is quite concerning is the lack of XUL support in Internet Explorer. I've begun reading posts on if this is a problem that can be corrected. I started this whole journey by wanting HTCs to run in Mozilla. I found this post that is a good attempt at making that a reality...

http://dean.edwards.name/moz-behaviors/

But what this really did was expose me to XUL. I was trying to get HTCs working and thought... why not just create XBL versions of my existing HTCs? In doing this I discovered something... XUL is far superior to any declarative syntax I found.

So I began playing with this. Interestly as I got more and more working in regular XUL under Firefox, I realized this could be used to make applications instead of the HTC-based system I currently use. But the big challenge is that these applications would not be supported by IE... which is currentlt what all our customers use. This is obviously a big problem. So, I remembered what Dean Edwards had done getting HTCs to work in Mozilla and figured that since XUL/XBL is XML based, the opposite could be done for IE.

I began using Client-Side XSLT in IE to make this transformation. I am still working on this and will hopefully have more to report soon. I have sucessfully gotten IE to make XUL look like it should and act like it should (with box layout), but I need to work a little more on this.

Before I put too much more work into getting XUL to look good, I'm going to begin researching three of the more difficult integration points:

1. Binding XBL to elements, presumably by rewriting the CSS to match the generated HTML and then adding a generic HTC behavior that knows how to read XBL, etc.
2. Somehow mimicing general XPCOM components, and how to support other ones.
3. Runtime changes to properties
4. Binding controls to RDF datasource. I think this can be done through the client-side XSLT.

Hopefully I'll have more to report soon and a URL where these files will reside.

Starting the Blog

This is just a note to let you know I have officially started a blog. Hopefully this will be used to share some of my ideas with my development team, and maybe the world. I'm still getting used to this so please stay tuned as I work with the interface.