Common interface for all UI components

[Jemt]

Not all controls/components inherit from a common interface.

Base classes:

• ControlBase (defined by Core)
• PickerBase (defined by DropDown control)

Inheriting from ControlBase (edit controls):

• CheckBox
• DatePicker
• DropDown, WSDropDown
• FilePicker
• Input
• TreeView, WSTreeView

Inheriting from PickerBase (defined by DropDown):

• ListView, WSListView
• TreeView, WSTreeView

Not inheriting from anything:

• Button
• ContextMenu, WSContextMenu
• Dialog
• ProgressBar

These components have to implement the same logic again and again (e.g. support for Fit.Controls.Find(..)). But what's equally annoying, is that we have to use feature detection to determine whether a component is for instance disposable or not - we cannot simply rely on type information.

We actually have other objects that also doesn't inherit from anything, but that's alright as they are not intended for use as separate components, but as child components:

• TreeViewNode
• ContextMenuItem

What we want is for all objects useful as separate UI components to at least implement the following basic functionality. First and foremost to reduce duplicated code and ensure consistency, and to ensure that all components can reliably be disposed without relying on feature detection.

• Constructor that takes a control ID that makes the control accessible using Fit.Controls.Find(..)
• GetId() that returns the control ID
• GetDomElement() that returns the DOM representation
• Render() that renders the control to DOM
• Dispose() that releases allocated memory by disposing all objects used by a component

[Jemt]

For consistency all controls will now allow instantiations without passing an ID to the constructor. If no control ID is passed, an ID will be automatically generated. This also means that all controls will now be accessible using Fit.Controls.Find(..).
It seems simply passing Fit.Data.CreateGuid() has become quite common, completely eliminating the intention to enforce meaningful IDs - but there are actually good reasons for using dynamically created IDs, such as to make access to the controls difficult to prevent external manipulation.

[Jemt]

PickerBase also implements logic similar to Component (previously found in ControlBase) - for instance it makes the control accessible through Fit.Controls.Find(..) and defines GetId() - both of which only Component should define.