Bug 172193 [DataBinding] Binding customization story
From IM... 10:12:10 PM brad: this is sort of a short in the dark but do you get confused by the method names in BindSpec? when i look at BindSpec i always think of either target -> model or model -> target. i'm not sure if i could come up with a way that wouldn't be as confusing to me but was curious if it confuses you at all. 10:13:04 PM boris: Two BindSpec, one for each direction? 10:15:21 PM brad: not exactly. what i get confused about are methods like setTargetToModelConverter and setTargetUpdatePolicy. (this is probably silly) but when i think of any set for target i always think of going from target to model. but instead setTargetToModel goes from target to model but setTargetUpdatePolicy is for model to target. 10:15:46 PM brad: i normally think of the pipeline when setting these values, for some reason it's easier for me. 10:16:01 PM brad: if it doesn't confuse you don't worry about it, i'm not always typical 10:16:24 PM boris: Would it be easier with two constants, TARGET_TO_MODEL and MODEL_TO_TARGET, and each method taking an int? 10:16:39 PM boris: It would cut down on the number of methods... brad10:17:03 PM brad: either that or having a naming convention that's a little more consistent (setTargetToModelUpdatePolicy(...), etc.) 10:17:31 PM brad: it might get a little verbose having to specify the direction for each method... 10:17:36 PM boris: T2M and M2T? 10:17:46 PM brad: yeah
bundles/org.eclipse.core.databinding/src/org/eclipse/core/databinding/DataBindingContext.java
/**
	 * Binds two observable lists using converter and validator as specified in
	 * bindSpec. If bindSpec is null, default converters and validators as
	 * defined by {@link DefaultBindSpec} will be used.
	 * <p>
	 * The phases performed for a list binding occur in the following order for
	 * each event: {@link BindingEvent#EVENT_COPY_TO_MODEL} and
	 * {@link BindingEvent#EVENT_COPY_TO_TARGET}:
	 * <ol>
	 * <li>{@link BindingEvent#PIPELINE_AFTER_GET}</li>
	 * <li>{@link BindingEvent#PIPELINE_BEFORE_CHANGE}</li>
	 * <li>{@link BindingEvent#PIPELINE_AFTER_CHANGE}</li>
	 * </ol>
	 * Multiple validators are honored for every phase except
	 * <code>BindingEvent.PIPELINE_AFTER_CHANGE</code> (it doesn't make sense
	 * to validate after the change is applied). Validators will be invoked in
	 * the order that they are added and a failure in validation will terminate
	 * pipeline processing. The provided validation status will be propagated to
	 * {@link Binding#getValidationStatus()} and
	 * {@link #getValidationStatusMap()}.
	 * </p>
	 * <p>
	 * All phases perform the duty their name implies except
	 * <code>PIPELINE_BEFORE_CHANGE</code>; it has no defined role in the
	 * pipeline. This phase is provided as a means to perform validation during
	 * data entry but to defer other validation until a copy to the model is to
	 * occur. A common use case where this is employed is the editing of a model
	 * in a dialog. The model should not be updated until OK/Apply is selected
	 * but common validation (e.g. type and range checking) is to be performed
	 * as the user is interacting with the UI. The following {@link BindSpec}