Design a scheme for lookup of individual widgets

[Updownquark]

I despise the id and name concepts in HTML, but I can't think of a better scheme off the top of my head to use to query the document for a given widget. This will be needed in a couple situations that will eventually arise:

• If MUIS is used as a front-end whose view components need to be retrieved by external code
• If unrelated widgets need to refer to each other, such as when a button's action effects a different pane

The plain name approach is flawed because instantiating two copies of the document or the complex widget will mean two results for the same name or id. Think of a better way.

[Updownquark]

Got it! Make the notions of properties and application events, like in PRISMS. Have the document manage properties and invoke property change and event listeners. Widgets can have their state managed by properties and events.

Maybe we can make a syntax for an attribute value on a widget like "${property.name}" so that when an attribute is given this syntax, the value of that attribute is the value of the named property and cannot be changed except by changing the property. Also something like "$[event.name].property" so that whenever an event named "event.name" is fired, the attribute value is set to the "property" property of that event. This kind of attribute should probably be updatable from code also, unlike the property one.

If users really want to retrieve widgets by name, they can use groups. Use group="group.name", then retrieve that group from the document and get the elements associated with that group.

[Updownquark]

This is no longer needed or a good idea. #37 does what this intended much better. Kind of got close to the right way of doing things with that last comment, though.