Ionrock Dot Org

My Weblog

Hybrid Widgets

It has been really interesting to think about how jquery ui fits within the design of our applications at work and the concept of a "widget". On the one hand, a widget is very much a javascript/jquery plugin in that it effectively must do all its communication over with ajax and is in fact loaded via ajax. The converse is that the HTML generated often comes directly from the server. There is always a struggle in my mind where this division really should be and while "it depends" definitely holds true, the scenario that helps define best practices seems to allude finding a set of general rule of thumb ideals.

When I worked at Novell in college it was when they were venturing into the webmail space with Hula. The idea for Hula was a webmail app that rivaled desktop applications while still providing an open platform for both email and calendaring. I got to see demos of the UI and was always impressed with what they were doing. When I looked at the source there was a huge gap when trying to find templates that defined the look and feel. In talking to the developers, the entire UI basically was constructed via javascript and only passed data back and forth to the server. At the time it seemed like a perfect idea.

Well, time seems to be the best tester of software as Hula was eventually dropped. I remember seeing cool demos here and there, but it was obvious it was a huge burden building the UI in this way. The process was slow and difficult to debug. Like any major javascript application, testing across supported browsers is most definitely an issue. In the end, it seemed that while the design seemed solid, the actual practicalities of building a UI completely in javascript was too difficult to overcome. I'm not saying that this is what sunk the project, but it was clear it was an issue.

What is interesting then is that jQuery UI uses a similar pattern of forcing the widget to write the HTML. This really isn't a problem in this respect because the widgets are limited in scope and must be decoupled from any specific application. In my use case at work, a widget also encompasses a server component, which makes using jQuery UI widgets more difficult. There are things the server markup must provide that the widget knows about and our requirement for decoupling is much less.

The goal then is to find a way to create a widget that has a specific server component while still writing generic widgets that can be decoupled in terms of each other, while still keeping the ease of integration required. The design I'm coming up with then is effectively a hybrid approach that aims to allow the server side templates define the majority of the widget and rely on specific cues to communicate the coupling between the javascript and the widget markup.

A good example would be a list of inputs. If you select one input, the values of the others must be cleared. So, the markup for the inputs should all be given semantic class names to help make it clear what the set of inputs are. This is usually unique according to the question's unique ID. Then any sort of grouping element would also be used to delineate the border or limits within the DOM the widget should not effect. Finally, the markup should utilize an internal data structure for keeping track of state that is verified through DOM elements. In other words, a two pronged attack at making sure the widget does the right thing when different events occur.

My goal is to keep the template changes to a minimum past changing the semantic classes and rely on the javascript be flexible to handle small changes in markup as needed. The way this all will need to come together is through configuration. The widget initializer will need to include the border or root element from which the widget works as well as the selectors for any nodes that need to be used as reference points. In terms of actual code then, the basic design will be a widget that does the generic functionality and then a set of initializers that will handle adding the context specific aspects.

Hopefully this small change will help make the difference for implementing widgets in a way that provides the flexibility we're beginning to need. Also, my hope is that in the future we can write the actual widget javascript to be more modular from the beginning instead of having to special case things so much afterwards. While the code often seems pretty simple, it becomes clear there is too much coupling between the server templates and the client side javascript. The result of this coupling is that small DOM changes wreak havoc on the functionality, when arguably, it should be relatively benign changing the look and feel or style. Likewise, no one wants to be tied down dealing with massive abstractions and libraries, so simplicity is a must.

The design is still very much in the air, but the ideas seem to be settling. I don't imagine that when it is all said and done things will be radically different. I also think that limiting the changes is probably a good thing and will help provide a healthy constraint for simplicity.