My experience implementing the pre-release UI Options

Colin Clark colinbdclark at gmail.com
Mon Aug 8 23:41:02 UTC 2011


Hi everyone,

I spent a few hours this weekend working with Johnny Taylor's cool new FSSFive theme for WordPress. FSSFive is a simple, clean theme that combines a good foundation of HTML5 markup with the Fluid Skinning System. 

https://github.com/abledaccess/FSSFive

My mission was to make it work with UI Options. Here's what I did, and what I learned.

First off, I made a custom build of Infusion containing only UI Options and its dependencies. Knowing that our production builds contain some extra fluff, I pruned out all directories containing individual JavaScript files and used the concatenated MyInfusion.js file exclusively.

After getting my copy of Infusion ready and in the right place within the WordPress theme, I hit the books. Knowing UI Options had changed a lot over the last week, I was worried that the documentation might already be out of date. I was pleasantly surprised to see just how accurate and current they were, as well as being really easy to follow. Nice job, Anastasia!

There were a couple of minor mistakes in the documentation. Here's a quick summary:

1. The stylesheet dependencies are missing the -uio suffix
2. For standard configurations, the "relativePrefix" and "markupRenderer" options (whatever they are) are no longer necessary
3. The button in the sample markup reads "This is the Show/Hide Button," which might be better as "Show Display Preferences" or something real

Another interesting issue I encountered with the documentation:

We tell users to place the initialization code for UI Enhancer and UI Options inside a call to jQuery.ready(), which will fire when the page's markup has fully rendered. However, we know that UI Enhancer needs to do a fair bit of DOM manipulation to restyle the page. It's probably best to do this as early as possible, before most of the page has been rendered by the browser. By the time jQuery.ready() fires, it may be late enough to cause some flickering.

For FSSFive, I placed the initialized code for UI Options and UI Enhancer immediately after UI Options' markup at the top of the <body>. UI Enhancer could be initialized earlier, and might even be best placed right at the top of the <body> element. I was a bit worried that this wouldn't work in IE 6, but it seems to be just fine.

In terms of code and configuration issues:

1. When I set UI Options' "prefix" option, I encountered a perplexing problem. The templates failed to load because UI Options seemed to be using some very bizarre URLs. They looked something like this:

":8888/wordpress/http://localhost:8888/wordpress/wp-content/themes/FSSFive/infusion/components/uiOptions/html/UIOptionsTemplate-text.html"

I was using a built-in WordPress variable to output absolute URLs to my theme's directory. It appears that UI Options' new URL rewriting feature only works with relative URLs. I've filed a bug for this, and I consider it a blocker:

http://issues.fluidproject.org/browse/FLUID-4393

Another issue I encountered was my own fault, but points to the need for improved error messages within the framework. As mentioned earlier, I was looking for the earliest time I could instantiate my page's UI Enhancer, trying to avoid any potential rendering flicker when the Enhancer changes the styling of the page. My first attempt was to place the call to fluid.pageEnhancer() in the <head>, figuring this guaranteed that the UI Enhancer would be instantiated before any subsequent markup had been rendered.

However, under the covers the pageEnhancer is a typical Infusion View: it expects to bind itself to a container element in the DOM. The framework was throwing an error while instantiating the UI Enhancer due to the fact that the <body> tag didn't yet exist. Fair enough, but the only error message I received in the console was "that is null." A bit of digging into the stack trace pointed me at the problem, but a more meaningful and helpful message about the failure of fluid.container would be more helpful. Only experts could decipher this issue without help.

The last sticky issue I encountered had to do with the iFrame in the Fat Panel version of UI Options. I had set up the head of each page in the FSSFive theme to only link to MyInfusion.js, but was seeing errors in the console related to each of UI Options' separate JavaScript dependencies. I knew I hadn't linked to these, so I was confused about where they were coming from. After a bit of digging, I realized that FatPanelUIOptionsFrame.html, used as the document for Fat Panel's secret iFrame, included script tags for each of UI Options' dependencies individually. I needed to change it to link only to MyInfusion.js. This is easy enough to do if documented, but could cause upgrade headaches in the future when a new version of Infusion is released. I've filed a bug about this, but I don't think it's a blocker for 1.4:

http://issues.fluidproject.org/browse/FLUID-4394

UI Options is looking pretty nice in WordPress. I don't have a screenshot yet, but here's my fork of FSSFive in case you want to try it out yourself:

https://github.com/colinbdclark/FSSFive

The last lingering problem I experienced, which we can continue to refine for this release and the next, is related to speed and smoothness. Introducing the Fat Panel version of UI Options adds some noticeable load time to my page, which is a disincentive to use it. We need to tighten up load time a bit. Also, as it starts up, the panel is initially visible but blank, spends a second or two doing something, and then rolls itself up. This jerkiness is noticeable and off-putting to users. I know there are some good technical reasons for this bug, but do you think it's something we can look at before freeze?

All in all, the process was pretty smooth. I think this is a good sign of how close we are getting to freezing and shipping it. Nice work, everyone!

Colin

---
Colin Clark
Technical Lead, Fluid Project
http://fluidproject.org



More information about the fluid-work mailing list