Updownquark
commented
11 years ago Just thought of a problem with the way I'm doing this. It would be possible to have a nested template widgets in such a way that roles could potentially conflict. For example, a combo box widget whose items have a role "item" may be contained in a templated widget with this template XML:
<template>
<combo>
<element role="item" template:attach-point="item2" />
</combo>
</template>So the main XML to specify the second template widget could specify content of role "item2" which would then be passed to the combo box to be interpreted as role "item". This is a valid use case and needs to be permitted easily and cleanly.
One way is for each template type to have its own role attribute. Each instance could have its own attribute also, but this is not necessary as templates cannot be recursive. Right now, I think the attribute manager enforces name uniqueness, so the name of each attribute would have to be different. Should we change this to allow multiple attributes of the same name? Can we hide the inner role attribute from the outside somehow?
I started on this years ago, but I don't remember any of my ideas. The code is still there, but MUIS has changed around it so much that it may need to be rewritten.
The idea is that a logical widget may be a collection of many simpler widgets working together. For example, a combo box is a combination of a content pane (perhaps a text field), a button (with the down arrow) and a menu. It should be possible to specify a combo box in the XML with its options directly like
without worrying about all the components needed to implement it and without needing to create those components programmatically.
The template functionality allows a widget class to parse a separate XML file containing the widget as a set of component widgets. In addition to the widgets, this file contains markers called "attach points" that label the individual components for easy retrieval from source code (e.g. the "menu" attach point would be the menu widget of a combo box). The widget needs easy access to its children as specified in the main XML (where the templated widget is invoked) such that they are not necessarily added to the widget as children directly, but are given to the widget as content to do what it likes with them. This may necessitate multiple calls to initChildren().
The children (from main XML) of a templated widget might not even need to extend MuisElement. For example, you might specifiy a data model that a widget is to use as an XML element (an attribute would not allow much configuration of the model in XML).
Templated widgets may contain templated widgets in their template XML description. Any MUIS application, no matter how complex, should have a root MUIS file of only a few kilobytes. All that needs to be specified in the root file is one or possibly a very few top-level widgets and a bit of configuration data in the attributes. Those widgets then populate themselves with other widgets from their template XMLs and so on to make the full depth of the application's structure.
This is crucial functionality for complex widgets and needs to be thought out carefully and implemented well the first time, even though it will probably be refactored and improved as more complex widgets are developed.