A naive control
	* delegates handling of user-generated events - for instance mouse clicks - to a separate, usually pluggable, event handling object
	* updates its visual representation only in response to the setting of its property values

A naive control does not:
	* directly handle events generated by the user
	* directly update itself from the domain models

''Not sure I understand what this means. Can someone give a simple example?''

''Maybe this is a Java thing & the author expects familiarity with AWT terms. --PhlIp''

----
ActiveX controls would be NaiveControls by this definition, in that:
	* they delegate handling of events to the container's sink object
	* they only update their visual representation (if at all) in response to a change in their property values or to a method call (which is essentially the same thing).

I have a problem with this definition of a NaiveControl because:
	* directly handling events generated by the user
	* directly updating from domain models

...ties the control too closely to the domain model, making it impossible to reuse in another, even slightly different, domain.

The correct way to leverage a NaiveControl (by this definition) and achieve domain applicability is to place the control in a MetaControl (better name?) which gives the outward appearance of the control (perhaps adding certain methods/properties), but handles the domain-specific responses.

-----
It is a couple of months since I made the comment above about not understanding this and after thinking about it I'm still not sure. Isn't this just a document-view architecture done properly. The controls know how to display their data and interact with the user and how to notify the application logic when something changes. The application logic knows which user interface objects care about their data, and how to tell those objects the value of new data.

Have I missed something?

-----
I think it extends doc-view to handle a couple of new things:

	* The u/i designer can choose from a variety of widgets for editing a piece of data.  Data that is one value in a given set (such as Month) can be displayed using a list box, edit control, radio buttons, etc.  Part of the u/i design is choosing which widget to use.  There is commonality here that the pluggable event handling object can isolate such as: loading the widget with the list of available values, validating a value, etc.  Once the pluggable event handling object has been added, then changing the u/i becomes much easier.

		* ''Why does doc-view only have one view per document? Even MFC doesn't do this.''  '''See rewritten paragraph above.'''

	* There may be dependencies between pieces of data that the model doesn't enforce.  Often changing one value in a dialog should cause greying or ungreying of other widgets.  Again there is commonality here that can be refactored to the pluggable event handling object (we need a better name!)

--IanRae

----

See also Mediator in DesignPatterns.