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
}
	/**
	 * Add a listener to the set of listeners that will be notified when an
	 * event occurs in the data flow pipeline managed by any binding in this
	 * data binding context.
	 * 
	 * @param listener
	 *            The listener to add.
	 */
	public void addBindingEventListener(IBindingListener listener) {
		bindingEventListeners.add(listener);
	}
	/**
	 * Binds two observable values using converters and validators as specified
	 * in <code>bindSpec</code>. If <code>bindSpec</code> is <code>null</code>,
	 * default converters and validators as defined by {@link DefaultBindSpec}
	 * will be used.
	 * <p>
	 * The phases performed for a value 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_VALUE_CHANGING} (target to model only)</li>
	 * <li>{@link BindingEvent#PIPELINE_AFTER_GET}</li>
	 * <li>{@link BindingEvent#PIPELINE_AFTER_CONVERT}</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).