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
* 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} configuration will setup such a use
	 * case:
	 * 
	 * <pre>
	 * <code>
	 * new DefaultBindSpec().setModelUpdatePolicy(BindSpec.POLICY_EXPLICIT)
	 * 		.addTargetValidator(BindingEvent.PIPELINE_BEFORE_CHANGE,
	 * 				new Validator());
	 * </code>
	 * </pre>
	 * 
	 * By default with a 
	 * {@link BindSpec#setModelUpdatePolicy(Integer) model update policy} of
	 * {@link BindSpec#POLICY_EXPLICIT} validation is ran up to and including
	 * <code>BindingEvent.PIPELINE_AFTER_CONVERT</code> on every change of the
	 * target. In the above example the provided validator will only be invoked
	 * on an explicit model updates {@link Binding#updateModelFromTarget()}.