Updownquark
commented
11 years ago A few more thoughts: The models should be both referrable and definable from XML. Complex application models would typically be written in java code, then referred to from XML (by fully-qualified class name, I'm thinking, to be instantiated by MUIS and retrieved by the application from the MUIS document later). But templates, for example, would generally need to instantiate their own models, which would then interact with properties on user-defined models. The template models might be best defined in XML. Still need more thought on this.
Thought of maybe having a MuisModel interface that is basically a mapping of string keys to properties or simple models. This would be what the MUIS widgets would deal with and the more complex models would not need to implement this, but a wrapper implementation would implement it and use reflection to get the properties and models from the complex model. Just an idea.
This feature needs to have a lot of power available to it (e.g. the model should be able to define the value and increment/decrement scheme for a spinner), but must also have a very simple use (e.g. just specifying an integer that the spinner displays, allows editing, and increments/decrements). This feature is super important.
One of the biggest problems with GUI's not generated directly by application code is widget lookup. One has to use an ID or some such construct to retrieve the widget, then populate it with values and add appropriate listeners. Either that or the GUI becomes the backbone of the application, assembling all the pieces in a user-interface-centric way.
I have an idea to avoid either of these two situations. Define a model scheme that is property-centric. In MUIS xml files, either define or instantiate by type an application model that has in it a set of named, typed, bounded properties. When a widget is defined in that document, it may either refer to a controller defined in that application model, or refer to a property in the model (in which case a controller is automatically instantiated. These controllers are registered into the application model with a reference to the widget.
For example, an application model is defined in the XML with a floating-point property. A spinner is defined later referring to this property. A spinner controller is instantiated and registered with the model for the property which links the value of the property in the model with the spinner's value both ways. An incrementor and/or decrementor may be defined for the widget and/or the property (with the widget's values overriding the default set for the property) to control what happens to the value when the up or down button is pressed.
From application code, the application model is retrieved from the document and its properties are linked with application values or used as those values. The application never needs to know how the properties are being modified by the user. More than one view into a set of properties can be constructed without modifying application code or previously built GUIs. Although inadvisable, it would be possible to access the widgets themselves through the models via the registered controllers. Even though this should not normally be necessary, it would be much cleaner than referring to widgets by name or ID.
This will make #12 unnecessary.