Misc. notes about the rework of Attribute Editors that I'm working on.

(Legend: "AE" = attribute editor, "DV" = detail view)

Issues:

• Labeling (display of a label external to the editing control) is something added by LabeledAttributeEditor, which inherits from BaseAttributeEditor; StringAttributeEditor inherits from it, but other non-string editors don't, which means that either the non-string editors have to "override-away" the string behavior or roll their own labeling.
• Sample text (display of a non-value message when the current attribute value isn't set or is some "default" value [easy for strings, but TBD for dates!]) needs tightening up...
• Additional behavior needs to be added, including:
  • Consistent mechanisms for margins, alignment, font handling
• I want to investigate using synchronous repository-level monitors from individual attribute editors, to get rid of the issues caused by the idle-time DV query
• Our model needs to include multiple editors of different parts of the same value: the new design for date entry has separate "date" and "time" editboxes.
• Need to work with Katie and/or Alec to see whether it'd be useful for the calendar canvas to use an AE instead of rolling their own control.
• Live validation needed, to enable the Send button as soon as the "to" field contains valid addresses.
• Need to validate that the AE design can handle all foreseeable DV editors
• For the future, we need to understand how AEs should work with printing.

Who are the customers of AEs?

• the detail view (via AEBlock)
• the summary table (eg, wx.Grid's editor/renderers)
• possibly CalendarCanvas, eventually (if it solves problems that currently must be solved independently in CalendarCanvas, like notification?)

How should multi-control attribute-editing work?

The existing AE model (as developed from the requirements of wx.Grid editor/renderers) require that an AE expose one control during editing; however, it might be possible for an AE to only expose one "active" control at a time. This would allow the AE access to both fields before writing back to the item; however, it may end up hard-coding bad assumptions into the editor (for instance, we plan a label between the editctrl boxes: it seems desirable to not have the AE own that.)

So, I think separate independent attribute editors should be used. The issue to keep in mind here is that our model requires that the item be valid at all times: we'd need a mechanism in the content model to store "no valid date/time", "invalid date + valid time", and "valid date / invalid time" (the latter being the right value for an "anytime" event's time, though it appears we're dropping anytime support in 0.6.) - each editor would only modify its own characteristic.

Where should labeling and layout behavior live? What about sample text?

Note that "labeling" is distinct from "sample text".

Labeling is only needed by the detail view, so it seems desirable to not bulk up the attribute editor classes with labeling (and the associated margin stuff, font selection, etc).

Sample text needs to remain an AE characteristic. It needs to be flexible, though: some attributes don't always display hints : "to" only displays "add invitees" when a mail message is stamped as a calendar event.

Layout behavior includes margins and alignment. It's a requirement that the left edges of editors line up, and probably means that this alignment should happen dynamically (so that when a new editor with a long name becomes visible, the other labeled editors realign automatically as part of wxSynchronizeWidget).

I'm guessing that a future requirement will be for editors to resize themselves vertically, so that (for example) the "to" list on an email message can display more addressees than will fit in a single-line field (and of course will be vital for printing). While I'm not implementing this today, I'm trying not to preclude adding this in the future. Thus, I think it'd be useful for the AEBlock to ask its editor to determine its own size programmatically (eg, based on the configured font).

What layout behaviors are needed?

• Consistent margining for all editors (except the body)
• Centralized label width (labeled editors report minwidth to the DV root, which stores the maximum minwidth and uses it to size the markup bar's indent)
• Consistent font specs? (vs each editor being configured with its own reference to the font spec?)

So, then, a labeling plan:

• Labeling will be handled by a LabelBlock that'll derive from the static text block. It'll be hosted in a RectangularChild^?, with AEBlocks as siblings. (This pretty much matches what we had before we built the initial AE blocks.
• It will get its label from its parcelXML by default, and if not specified, its first child AEBlock's attribute's displayName.
• It'll measure the label and report its width to the DV, and size itself based on the DV's labelwidth specification. (Measuring all LabelBlocks will need to happen before any LabelBlock can size itself.)

How should monitoring/notification change?

The current notification model doesn't work well for the detail view:

• It's asynchronous; notifications only happen at idle time; this means that notification calls might long after the changes that triggered them (eg, normal-speed typing can hold off notifications until the user pauses; while this delay isn't a problem for [for example] menu enabling, it is a problem for view synchronization: there's no simple way (without a lot more scaffolding) for the detail view's editors to know whether they should copy a value from the item to replace a value in an editor. (Note that the changes the DV makes trigger notifications, which the DV must decide how to handle.)

The repository provides a lower-level mechanism that looks tailor-made for the detail view's needs:

• It's synchronous, which means the DV will have an easier time deciding to ignore its own notifications.
• It uses a monitor per attribute, which would match well with per-attribute-editor monitoring. Each AE can decide whether it can simply replace the value in the editor (or whether it should!), or whether it needs wxSyncWidgets called to re-lay-out the entire DV.
• This monitoring could be handled within the attribute editors, which would simplify the DV and also give a reason for the CalendarCanvas to use an AE instead of rolling its own textbox.

How should Live Validation work?

• The EmailAddressListAE will set the app-wide needsUpdateUI flag on each keypress that changes the value in the email editor.
• While it'd be nice to have a mechanism to isolate the DV from the knowledge about editor state, I think the simplest model would be for the DV to look for the toAddress AEBlock by name, and call a (new) IsValidNow method that would test the value in the editor if the editor happens to be active for editing.
• (Are there any other fields where current validity is a concern for UI enabling?)