Label as optional part for Button

Issue

Currently, in order to make a text item in a Button skin be a label, you have to data-bind it to the "label" property of Button. In Thermo, we would like to avoid having designers encounter data-binding when doing simple skinning of common controls, and it seems to make sense to make label be an optional part in the Button skin contract, for convenience.

Proposal (8/22)

  1. Add an optional "label" part to Button, its subclasses, and any other labelled component that has Button-like behavior, of type TextGraphicElement.
  2. Components with a "label" part are responsible for pushing the value of the label property into the label part.
  3. For all components, if a skin part needs to be bound to data, the component is responsible for pushing the data into the skin part, rather than requiring the part to use data binding to pull the data.
    1. (8/22) Ryan F raised a concern that having data being automatically pushed from the component into the skin will make it harder to tell what's going on just from looking at the skin code. However, he didn't strongly object to going ahead with the present proposal.
  4. For new components, consider adding optional parts for properties that designers/developers are likely to want to expose in the skin, even if those items are pure data items with no specific behavior.

Questions

  1. What would the type of the "label" part be? If we want flexibility, it would need to accommodate either TextView or TextGraphic.
    1. 8/22: Gordon says that Button can just use TextGraphicElement, which is the base class of TextBox and TextGraphic, while TextInput and TextArea can just use TextView.
  2. What's the general rule? Proposal: create optional parts for any common content property a component exposes.
  3. What about TextInput and similar? Proposal: controller should push data into the part, rather than requiring the skin to pull the data in via databinding.
    1. 8/22: General rule: if a skin item is a part, the component is responsible for pushing data into the part. Non-part skin items have to pull data using data binding.
  4. What's the list of components/parts that we want to treat this way? That would help us vet the proposals for questions 1/2 above.
    1. Button and subclasses: label
    2. Looks like that's it, based on the recent skin contract meeting.
  5. How about things like "icon" for Buttons? Currently, this isn't exposed as a property--you just have to use the content property. Proposal: no action, don't add this