"Jay Lawrence" <Ja...@La...> wrote:
>I've gotta claim ignorance on what you guys are talking about when you're
>refering to factories and controllers.
Controller is just a specific name for a factory in this case, except the
controller has certain configuration information the widgets can reference.
For example, the controller knows what rendering environment to use or which
state object to use by default. At least in my email, I use the two terms
controller and factory interchangably.
>Personally - I expected that I'd instanciate what ever widgets I the app
>developer wanted, fill their properties at instanciation or afterwards, and
>then call their methods when I needed something from them.
The controller/factory does some of this for you when you use it to create
widgets.
>I guess the purpose of having a controller or factory is to aid in this
>process? Possibly provide other services? Maybe I am thinking that
>controller code is slightly beyond scope of widgets.
-nod- The controller/factory handles configuration issues that are
pan-widget, basically. The dictionary, state object, and rendering
environment are controlled by the controller/factory in my code. The factory
also knows where to find the widget classes (Widget::* or some other
configurable base module name).
--
James Smith <JG...@TA...>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix
|
