Widgets, Gadgets, Controls. OH MY!
Lately I've started hearing terms like "widget", "gadget", "control", and "plugin" more and more and in different contexts. jQuery for example has a number of third party plugins. And even jQuery UI has made the widget idea concrete with a widget class (object). In the Zend Framework reference you can find the word widget mentioned. Google gadgets are elements that can be embedded inside of your own web page. And Zend Framework has it's Zend_Paginator which is referred to as a "control". Asp.net has a whole collection of so called "controls". The interesting thing is that what the iPhone calls a "control" (such as a text box) X-Windows calls a widget. This makes it obvious to me that these terms are often used interchangeably and which word is used often depends only on the software vendor. So why then is it so hard to define a clear and concise conventional definition of the concepts that each of these terms represent? What I intend to do on this page is to give you my conventional definitions for each of these concepts. With conventional definitions we should be able to clean up the muddy conceptual waters for the next web developer and establish some common terminology.
The Plugin Pattern
Before we get too far let me clear up one point of confusion; Plugins. The basic concept of a plugin is succinctly described by Jeremy Miller.
The general idea being that you extend the existing behavior of a framework by creating a class implementing an interface from the framework. Your new class doesn't call the framework; the framework code calls the new class.
In my own words. A plugin is an object who's type determines it's expected interactions with a larger framework allowing the end user the ability to extend or modify the behavior of that framework. This makes life easier for end users / web developers as they no longer have to worry about the infrastructure which allows them to focus on the new problem that must be solved. It turns out though that the word plugin is sometimes used to refer to particular types of widgets, gadgets, and controls. Specifically the ones that are implemented using the "Plugin Pattern". Understanding this eliminates one word from our list and lets us focus on the three remaining, which are my main focus.
Widgets, Gadgets, and Controls.
In my opinion each of these have nuanced differences with regards to the Zend Framework, but before we get to those, let's try to understand the similarity between them first. Each of these have at least two things in common. They are designed to be drop in loosly coupled additions to existing GUI functionality. In other words they are very portable blocks of code. Secondly interactions between the user and the application are implemented using the Target-Action design pattern. The Target-Action design pattern conceptually refers to some triggered object (typically GUI element triggered by a user), sending an "Action" to be performed to a "Target" object. An easy example is one of an HTML form. When a submit button is clicked it sends the action "submit" to it's parent "form" element (the target object) at which point the form element submits it's values to the specified script. These common characteristics allow us to place these ideas into a larger group. I call this group "Portable Human Interaction Components" or PHIC (pronounced 'fick')
The concept of PHIC allows us to find common ground among our terms widget, gadget, and control. This allows us to better articulate the conceptual differences between the 3 specialized versions of PHIC, which typically differ only by scale and context. I will confine the description of these versions within the context of their use within a Zend Framework backed application.
- Decoupled and configurable blocks of code that exist in the local installation.
- In some cases included as part of the overall layout via a view helper (see Zend_View_Helper_Action)
- In some cases exist as a stand alone (self rendering) object. Zend_Form is self contained, portable, and renders itself.
Although no user interaction is available with the twitter feed in the right bar. It is still a good example of a widget. It's being powered by a separate controller which is being rendered into the layout via Zend Framework's Zend_View_Helper_Action. Adding "next" and "previous" buttons is on the TODO list.
- Similar scale and functionality as a widget, but the context is different as it's usually a third party solution embedded via client side code. Think Google gadgets.
- Usually included within the overall layout.
- The scale of controls are typically smaller than widgets or gadgets. Think buttons, text fields, or advanced multi-select elements instead of larger elements such as calendar widgets.
- Usually decoupled local view scripts or view helpers. Zend_Paginator is a good example.
- Usually included within individual view scripts, and not included as part of the layout. A photo gallery for example would need a paginator control, which should not appear site wide typically.
Checkboxes, radio buttons, select boxes, textboxes, or even advanced multiselect are typical examples of controls. The intent of a control typically is to "control" work flow (submit buttons), data (input fields), or state (paginators).
I hope this gives you an acceptable convention for better understanding of the nature of each of these ideas. I know it's only my convention at the moment, but it definitely helps to have a nicely articulated definition instead of terminology that has many intermingled / interchangeable terms.
As always feedback is desired. Mail me. ~mrBurly.