http://wiki.eclipse.org/api.php?action=feedcontributions&user=Bradleyjames.gmail.com&feedformat=atomEclipsepedia - User contributions [en]2015-08-02T21:56:32ZUser contributionsMediaWiki 1.23.2http://wiki.eclipse.org/Template:JFace_Data_BindingTemplate:JFace Data Binding2007-11-18T19:02:20Z<p>Bradleyjames.gmail.com: </p>
<hr />
<div>&lt;noinclude&gt;<br />
Provides a navigation side bar for [[JFace Data Binding]] pages. The result is the side bar that you see in the lower right. This template creates a feeling of a site within the our documentation.<br />
<br />
===Usage===<br />
&lt;nowiki&gt;{{JFace Data Binding}}&lt;/nowiki&gt;<br />
<br />
The side bar right aligns itself. The recommendation is to put this towards the top of the page. It's normally found below the page description.<br />
<br />
&lt;/noinclude&gt;<br />
{| style=&quot;margin: 0 0 0.5em 1em; border: 1px solid #aaaaaa; float:right; clear:right; border-collapse:collapse;&quot; cellpadding=1<br />
|-<br />
| style=&quot;background:#ccccff; padding: 0 5px 0 5px;&quot; align=&quot;center&quot; | &lt;strong&gt;JFace Data Binding&lt;/strong&gt;<br />
|-<br />
| style=&quot;font-size: 90%; padding: 0 5px 0 5px;&quot; align=&quot;center&quot; | [[JFace Data Binding | Home]]<br />
|-<br />
| style=&quot;font-size: 90%; padding: 0 5px 0 5px;&quot; align=&quot;center&quot; | [[JFace Data Binding/How to Contribute | How to Contribute]]<br />
|-<br />
| style=&quot;font-size: 90%; padding: 0 5px 0 5px;&quot; align=&quot;center&quot; | [[JFace Data Binding/FAQ | FAQ]]<br />
|-<br />
| style=&quot;font-size: 90%; padding: 0 5px 0 5px;&quot; align=&quot;center&quot; | [[JFace Data Binding/Snippets | Snippets]]<br />
|-<br />
| style=&quot;background:#ccccff; padding: 0 5px 0 5px;&quot; align=&quot;center&quot;| Concepts<br />
|-<br />
| style=&quot;font-size: 90%; padding: 0 5px 0 5px;&quot; align=&quot;center&quot; | [[JFace Data Binding/Binding | Binding]]<br />
|-<br />
| style=&quot;font-size: 90%; padding: 0 5px 0 5px;&quot; align=&quot;center&quot; | [[JFace Data Binding/Converter | Converter]]<br />
|-<br />
| style=&quot;font-size: 90%; padding: 0 5px 0 5px;&quot; align=&quot;center&quot; | [[JFace Data Binding/Observable | Observable]]<br />
|-<br />
| style=&quot;font-size: 90%; padding: 0 5px 0 5px;&quot; align=&quot;center&quot; | [[JFace Data Binding/Realm | Realm]]<br />
|}</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/Template:JFace_Data_BindingTemplate:JFace Data Binding2007-11-18T17:13:35Z<p>Bradleyjames.gmail.com: Added documentation on template usage.</p>
<hr />
<div>&lt;noinclude&gt;<br />
Provides a navigation side bar for [[JFace Data Binding]] pages. The result is the side bar that you see in the lower right. This template creates a feeling of a site within the our documentation.<br />
<br />
===Usage===<br />
&lt;nowiki&gt;{{JFace Data Binding}}&lt;/nowiki&gt;<br />
<br />
The side bar right aligns itself. The recommendation is to put this towards the top of the page. It's normally found below the page description.<br />
&lt;/noinclude&gt;<br />
{| style=&quot;margin: 0 0 0.5em 1em; border: 1px solid #aaaaaa; float:right; clear:right; border-collapse:collapse;&quot; cellpadding=1<br />
|-<br />
| style=&quot;background:#ccccff; padding: 0 5px 0 5px;&quot; align=&quot;center&quot; | &lt;strong&gt;JFace Data Binding&lt;/strong&gt;<br />
|-<br />
| style=&quot;font-size: 90%; padding: 0 5px 0 5px;&quot; align=&quot;center&quot; | [[JFace Data Binding | Home]]<br />
|-<br />
| style=&quot;font-size: 90%; padding: 0 5px 0 5px;&quot; align=&quot;center&quot; | [[JFace Data Binding/How to Contribute | How to Contribute]]<br />
|-<br />
| style=&quot;font-size: 90%; padding: 0 5px 0 5px;&quot; align=&quot;center&quot; | [[JFace Data Binding/FAQ | FAQ]]<br />
|-<br />
| style=&quot;font-size: 90%; padding: 0 5px 0 5px;&quot; align=&quot;center&quot; | [[JFace Data Binding/Snippets | Snippets]]<br />
|-<br />
| style=&quot;background:#ccccff; padding: 0 5px 0 5px;&quot; align=&quot;center&quot;| Concepts<br />
|-<br />
| style=&quot;font-size: 90%; padding: 0 5px 0 5px;&quot; align=&quot;center&quot; | [[JFace Data Binding/Binding | Binding]]<br />
|-<br />
| style=&quot;font-size: 90%; padding: 0 5px 0 5px;&quot; align=&quot;center&quot; | [[JFace Data Binding/Converter | Converter]]<br />
|-<br />
| style=&quot;font-size: 90%; padding: 0 5px 0 5px;&quot; align=&quot;center&quot; | [[JFace Data Binding/Observable | Observable]]<br />
|-<br />
| style=&quot;font-size: 90%; padding: 0 5px 0 5px;&quot; align=&quot;center&quot; | [[JFace Data Binding/Realm | Realm]]<br />
|}</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/Template:Bug_commentTemplate:Bug comment2007-11-18T17:03:55Z<p>Bradleyjames.gmail.com: Added documentation on template usage.</p>
<hr />
<div>&lt;noinclude&gt;Displays a link to a bug comment on Eclipse's bugzilla with the bug and comment numbers as the display.<br />
===Usage===<br />
; &lt;nowiki&gt;{{bug comment|153630|9}} -&gt;&lt;/nowiki&gt; : [https://bugs.eclipse.org/bugs/show_bug.cgi?id=153630#c9 bug 153630 comment 9]&lt;/noinclude&gt;<br />
&lt;includeonly&gt;[https://bugs.eclipse.org/bugs/show_bug.cgi?id={{{1}}}#c{{{2}}} bug {{{1}}} comment {{{2}}}]&lt;/includeonly&gt;</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/Template:BugTemplate:Bug2007-11-18T16:57:13Z<p>Bradleyjames.gmail.com: Added documentation on template usage.</p>
<hr />
<div>&lt;noinclude&gt;Displays a bug link with the bug number as the display.<br />
===Usage===<br />
; &lt;nowiki&gt;{{bug|153630}} -&gt;&lt;/nowiki&gt; : [https://bugs.eclipse.org/bugs/show_bug.cgi?id=153630 bug 153630]&lt;/noinclude&gt;<br />
&lt;includeonly&gt;[https://bugs.eclipse.org/bugs/show_bug.cgi?id={{{1}}} bug {{{1}}}]&lt;/includeonly&gt;</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/Conference_Call_Agenda_2007_11JFace Data Binding/Conference Call Agenda 2007 112007-11-08T05:44:35Z<p>Bradleyjames.gmail.com: Added bug 197798</p>
<hr />
<div>=== Data binding conference call on November 14, 2007 ===<br />
<br />
Time: [http://www.timeanddate.com/worldclock/fixedtime.html?month=11&amp;day=14&amp;year=2007&amp;hour=12&amp;min=0&amp;sec=0&amp;p1=188 12:00 EST Wednesday, November 14, 2007]&lt;br/&gt;<br />
Duration: 60 minutes<br />
<br />
To call in, dial +1 866-842-3549 (or alternatively: +1 613-787-5018), then enter the conference ID: 8864297#<br />
<br />
Participants: Boris Bokowski, Tom Schindl, Matt Carter, Kevin McGuire, Peter Centgraf, Matthew Hall, Dave Orme, Brad Reynolds<br />
<br />
=== Agenda ===<br />
<br />
* Short introduction (I would like to get to know new people a little --- Boris)<br />
* List of open bugs we want to tackle for M4, and 3.4 in general (Need this to focus my scarce time on the important issues -- Boris)<br />
** {{bug|144260}} CellEditor support and builder for viewers --[[User:Bradleyjames.gmail.com|Bradleyjames.gmail.com]]<br />
** {{bug|203492}} Binding builder investigation --[[User:Bradleyjames.gmail.com|Bradleyjames.gmail.com]]<br />
** {{bug|197798}} Provide support for Java 5 types --[[User:Bradleyjames.gmail.com|Bradleyjames.gmail.com]]<br />
* How to improve documentation<br />
* ...<br />
<br />
Please add more items as appropriate.</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/Conference_Call_Agenda_2007_11JFace Data Binding/Conference Call Agenda 2007 112007-11-07T04:17:46Z<p>Bradleyjames.gmail.com: Added bugs for 3.4M4</p>
<hr />
<div>=== Planned data binding conference call in November 2007 ===<br />
<br />
Please use [http://www.doodle.ch/participation.html?pollId=3aug2adg2brffbrk this link] to indicate when you are available for a call.<br />
<br />
=== Agenda ===<br />
<br />
* Short introduction (I would like to get to know new people a little --- Boris)<br />
* List of open bugs we want to tackle for M4, and 3.4 in general (Need this to focus my scarce time on the important issues -- Boris)<br />
** {{bug|144260}} CellEditor support and builder for viewers --[[User:Bradleyjames.gmail.com|Bradleyjames.gmail.com]]<br />
** {{bug|203492}} Binding builder investigation --[[User:Bradleyjames.gmail.com|Bradleyjames.gmail.com]]<br />
* How to improve documentation<br />
* ...<br />
<br />
Please add more items as appropriate.</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/Conformance_TestsJFace Data Binding/Conformance Tests2007-10-03T13:46:25Z<p>Bradleyjames.gmail.com: Added side bar and Data Binding category</p>
<hr />
<div>The JFace Data Binding Conformance Suite (TCK) is a suite of tests and other files that allow for asserting the conformance of implementations to the abstractions provided by the library. The conformance tests can be found in the org.eclipse.jface.tests.databinding.conformance project in the Eclipse CVS. The tests are available for public consumption but will not be released as 1.0 until the Eclipse 3.4 release.<br />
{{JFace Data Binding}}<br />
== Observables ==<br />
The TCK provides tests for the assertion of conformance to the observable specifications. Tests are currently provided for implementations of:<br />
* IObservable<br />
* IObservableValue<br />
* IObservableCollection<br />
* IObservableList<br />
* IObservableSet<br />
<br />
Tests are broken up into mutable and immutable test cases (e.g. ObservableValueContractTest and MutableObservableValueContractTest). The reason for this is that not all implementations allow for a consumer to mutate the observable via its API. The TCK tests assert the following when appropriate:<br />
* Change events and their diffs<br />
* Realm checking<br />
* ObservableTracker.getterCalled(IObservable) invocations<br />
* Values and value types<br />
<br />
The TCK tests don't assert the observed object state. Because the observed object can be of any type and the value can be in any form this isn't something that we feel we can reliably provide. It would be more straightforward for these to remain in your own tests.<br />
<br />
=== Delegates ===<br />
In order to take advantage of the tests developers will need to create a contract delegate. The delegates allow for implementation specific details to be provided to the TCK. The IObservableContractDelegate is provided below as an example:<br />
<br />
public interface IObservableContractDelegate {<br />
/**<br />
* Notifies the delegate of the start of a test.<br />
*/<br />
public void setUp();<br />
<br />
/**<br />
* Notifies the delegate of the end of a test.<br />
*/<br />
public void tearDown();<br />
<br />
/**<br />
* Invokes an operation to set the stale state of the provided<br />
* &lt;code&gt;observable&lt;/code&gt;.<br />
* <br />
* @param observable<br />
* @param stale<br />
*/<br />
public void setStale(IObservable observable, boolean stale);<br />
<br />
/**<br />
* Creates a new observable.<br />
* <br />
* @param realm realm of the observable<br />
* @return observable<br />
*/<br />
public IObservable createObservable(Realm realm);<br />
<br />
/**<br />
* Invokes a change operation on the observable resulting in a change event<br />
* being fired from the observable.<br />
* <br />
* @param observable<br />
*/<br />
public void change(IObservable observable);<br />
}<br />
<br />
The delegate API follows the standard JUnit conventions of setUp() and tearDown(). The other methods will be invoked when necessary by the tests.<br />
<br />
The delegates provided are:<br />
* org.eclipse.jface.databinding.conformance.delegate.IObservableContractDelegate<br />
* org.eclipse.jface.databinding.conformance.delegate.IObservableValueContractDelegate<br />
* org.eclipse.jface.databinding.conformance.delegate.IObservableCollectionContractDelegate<br />
<br />
Your observable implementation will determine which delegate to construct. Abstract implementations are provided to simplify implementing a delegate.<br />
<br />
=== Integration into Tests ===<br />
Since the tests are JUnit3 tests you can integrate them into your tests in standard ways. The two most common ways are by subclassing or creating a suite.<br />
<br />
==== Subclassing ====<br />
public class ButtonObservableValueTest extends SWTObservableValueContractTest {<br />
public ButtonObservableValueTest() {<br />
super(new Delegate());<br />
}<br />
<br />
/* package */ static class Delegate extends AbstractObservableValueContractDelegate {<br />
private Shell shell;<br />
private Button button;<br />
<br />
public void setUp() {<br />
shell = new Shell();<br />
button = new Button(shell, SWT.CHECK);<br />
}<br />
<br />
public void tearDown() {<br />
shell.dispose();<br />
}<br />
<br />
public IObservableValue createObservableValue(Realm realm) {<br />
return new ButtonObservableValue(realm, button);<br />
}<br />
<br />
public void change(IObservable observable) {<br />
boolean value = button.getSelection();<br />
button.setSelection(!value);<br />
button.notifyListeners(SWT.Selection, null);<br />
}<br />
<br />
public Object createValue(IObservableValue observable) {<br />
return (Boolean.TRUE.equals(observable.getValue()) ? Boolean.FALSE : Boolean.TRUE);<br />
}<br />
<br />
public Object getValueType(IObservableValue observable) {<br />
return Boolean.TYPE;<br />
}<br />
}<br />
}<br />
<br />
When subclassing, because of single inheritance, you will will have to create multiple implementations to test the mutable and immutable use cases (e.g. there would need to be a ButtonMutableObservableValueTest as well to test the mutable cases). The rest of the implementation should be straightforward. The only thing we ask is that you don't depend upon API other than the constructors. Tests are public because JUnit requires them to be, not because we want to commit to them as API. Over time we would like to have the opportunity to rename, add, remove, or optimize the test methods to ensure that we're getting the best coverage as possible. Because of the issues outlined above the preferred method is creating a JUnit suite.<br />
<br />
==== JUnit suite() ====<br />
public class ButtonObservableValueTest extends TestCase {<br />
public static Test suite() {<br />
Delegate delegate = new Delegate();<br />
<br />
return new SuiteBuilder().addTests(ButtonObservableValueTest.class)<br />
.addObservableContractTest(<br />
SWTObservableValueContractTest.class, delegate)<br />
.addObservableContractTest(<br />
SWTMutableObservableValueContractTest.class, delegate)<br />
.build();<br />
}<br />
<br />
/* package */ static class Delegate extends AbstractObservableValueContractDelegate {<br />
private Shell shell;<br />
private Button button;<br />
<br />
public void setUp() {<br />
shell = new Shell();<br />
button = new Button(shell, SWT.CHECK);<br />
}<br />
<br />
public void tearDown() {<br />
shell.dispose();<br />
}<br />
<br />
public IObservableValue createObservableValue(Realm realm) {<br />
return new ButtonObservableValue(realm, button);<br />
}<br />
<br />
public void change(IObservable observable) {<br />
boolean value = button.getSelection();<br />
button.setSelection(!value);<br />
button.notifyListeners(SWT.Selection, null);<br />
}<br />
<br />
public Object createValue(IObservableValue observable) {<br />
return (Boolean.TRUE.equals(observable.getValue()) ? Boolean.FALSE : Boolean.TRUE);<br />
}<br />
<br />
public Object getValueType(IObservableValue observable) {<br />
return Boolean.TYPE;<br />
}<br />
}<br />
} <br />
<br />
By creating a suite() method you can create a custom suite of tests to run. This will allow you to run multiple TestCases from a single test eliminating the need to create multiple implementations for the mutable and immutable cases. The &lt;code&gt;SuiteBuilder&lt;/code&gt; implementation allows for a straightforward way to build these suites. The downside to building tests in this fashion is that when ran they don't contain the context of a parent class. In the JUnit view in Eclipse they are children of a junit.framework.TestSuite rather than a named test. As a way around this the failure message contains information about the context of the failure (e.g. Test class name and delegate name).<br />
<br />
[[Category:Data Binding]]</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_BindingJFace Data Binding2007-09-30T23:09:31Z<p>Bradleyjames.gmail.com: Added conformance tests link</p>
<hr />
<div>JFace Data Binding is a multi-threaded set of abstractions that allow for automated validation and synchronization of values between objects. This is commonly used for, but not limited to, the binding of user interface components to model attributes. The core concepts behind the project are [[Observables]] and [[Binding | Bindings]]. We provide IObservable implementations for SWT, JFace, and JavaBeans but the core is void of references to these in anticipation of implementations for other projects (e.g. EMF, Swing, etc.).<br />
{{JFace Data Binding}}<br />
== Articles ==<br />
=== Concepts ===<br />
* [[/Observable|Observable]]<br />
* [[/Binding|Binding]]<br />
* [[/Converter|Converter]]<br />
* Validators<br />
* [[/Realm|Realm]]<br />
* Master Detail<br />
<br />
=== Requirements and Design ===<br />
* [[JFace Data Binding Introduction]]<br />
* [[/Original Design | Original Design Document]]<br />
* [[/Scenarios | Scenarios Document]]<br />
<br />
=== Tutorials &amp; Presentations ===<br />
* [[Media:Databinding.pdf | Dave Orme's EclipseCon 2006 Lightning Talk slides]] ''(The code in this presentation is out of date and should not be used as an example but the concepts are still relevant.)''<br />
* [https://admin.adobe.acrobat.com/_a300965365/p77464314/ JFace Data Binding Webinar]<br />
* [[Media:Databinding.zip | Dave and Boris's EclipseCon 2007 long talk and slides]]<br />
<br />
=== Miscellaneous ===<br />
* [[/FAQ | FAQ]]<br />
* [[/How to Contribute | How to Contribute]]<br />
*[[/Wiki Guidelines|Wiki Guidelines]]<br />
*[[/Conformance Tests|Conformance Tests]]<br />
<br />
== Contact Us ==<br />
The [http://www.eclipse.org/newsportal/thread.php?group=eclipse.platform Platform newsgroup] is the place for discussions and questions relating to JFace Data Binding. When posting please prefix the subject with &quot;[DataBinding]&quot; to allow us to easily find posts related to the project.<br />
<br />
Design discussions and bugs are located on [https://bugs.eclipse.org/bugs/ Eclipse bugzilla] with a the values...<br />
; Classification : Eclipse <br />
; Product : Platform<br />
; Component : UI<br />
<br />
Like posts to the newsgroup when logging bugs please prefix the summary with &quot;[DataBinding]&quot; to allow for easier identification.<br />
<br />
== Getting Involved ==<br />
There are many ways to get involved with JFace Data Binding. To find out how you can contribute see [[/How to Contribute|How to Contribute]].<br />
<br />
==Project Release Status==<br />
JFace Data Binding 1.0 was releaseed with Eclipse 3.3, [[Europa Simultaneous Release | Europa]]. We're currently working on the [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=%5BDataBinding%5D&amp;classification=Eclipse&amp;product=Platform&amp;component=UI&amp;target_milestone=3.3.1&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=&amp;emailtype1=substring&amp;email1=&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0= 3.3.1 maintenance release] as well as enhancements for 3.4.<br />
<br />
[[Category:Data Binding]][[Category:Platform UI]]</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/Conformance_TestsJFace Data Binding/Conformance Tests2007-09-30T23:08:44Z<p>Bradleyjames.gmail.com: Added conformance test project name.</p>
<hr />
<div>The JFace Data Binding Conformance Suite (TCK) is a suite of tests and other files that allow for asserting the conformance of implementations to the abstractions provided by the library. The conformance tests can be found in the org.eclipse.jface.tests.databinding.conformance project in the Eclipse CVS. The tests are available for public consumption but will not be released as 1.0 until the Eclipse 3.4 release.<br />
<br />
== Observables ==<br />
The TCK provides tests for the assertion of conformance to the observable specifications. Tests are currently provided for implementations of:<br />
* IObservable<br />
* IObservableValue<br />
* IObservableCollection<br />
* IObservableList<br />
* IObservableSet<br />
<br />
Tests are broken up into mutable and immutable test cases (e.g. ObservableValueContractTest and MutableObservableValueContractTest). The reason for this is that not all implementations allow for a consumer to mutate the observable via its API. The TCK tests assert the following when appropriate:<br />
* Change events and their diffs<br />
* Realm checking<br />
* ObservableTracker.getterCalled(IObservable) invocations<br />
* Values and value types<br />
<br />
The TCK tests don't assert the observed object state. Because the observed object can be of any type and the value can be in any form this isn't something that we feel we can reliably provide. It would be more straightforward for these to remain in your own tests.<br />
<br />
=== Delegates ===<br />
In order to take advantage of the tests developers will need to create a contract delegate. The delegates allow for implementation specific details to be provided to the TCK. The IObservableContractDelegate is provided below as an example:<br />
<br />
public interface IObservableContractDelegate {<br />
/**<br />
* Notifies the delegate of the start of a test.<br />
*/<br />
public void setUp();<br />
<br />
/**<br />
* Notifies the delegate of the end of a test.<br />
*/<br />
public void tearDown();<br />
<br />
/**<br />
* Invokes an operation to set the stale state of the provided<br />
* &lt;code&gt;observable&lt;/code&gt;.<br />
* <br />
* @param observable<br />
* @param stale<br />
*/<br />
public void setStale(IObservable observable, boolean stale);<br />
<br />
/**<br />
* Creates a new observable.<br />
* <br />
* @param realm realm of the observable<br />
* @return observable<br />
*/<br />
public IObservable createObservable(Realm realm);<br />
<br />
/**<br />
* Invokes a change operation on the observable resulting in a change event<br />
* being fired from the observable.<br />
* <br />
* @param observable<br />
*/<br />
public void change(IObservable observable);<br />
}<br />
<br />
The delegate API follows the standard JUnit conventions of setUp() and tearDown(). The other methods will be invoked when necessary by the tests.<br />
<br />
The delegates provided are:<br />
* org.eclipse.jface.databinding.conformance.delegate.IObservableContractDelegate<br />
* org.eclipse.jface.databinding.conformance.delegate.IObservableValueContractDelegate<br />
* org.eclipse.jface.databinding.conformance.delegate.IObservableCollectionContractDelegate<br />
<br />
Your observable implementation will determine which delegate to construct. Abstract implementations are provided to simplify implementing a delegate.<br />
<br />
=== Integration into Tests ===<br />
Since the tests are JUnit3 tests you can integrate them into your tests in standard ways. The two most common ways are by subclassing or creating a suite.<br />
<br />
==== Subclassing ====<br />
public class ButtonObservableValueTest extends SWTObservableValueContractTest {<br />
public ButtonObservableValueTest() {<br />
super(new Delegate());<br />
}<br />
<br />
/* package */ static class Delegate extends AbstractObservableValueContractDelegate {<br />
private Shell shell;<br />
private Button button;<br />
<br />
public void setUp() {<br />
shell = new Shell();<br />
button = new Button(shell, SWT.CHECK);<br />
}<br />
<br />
public void tearDown() {<br />
shell.dispose();<br />
}<br />
<br />
public IObservableValue createObservableValue(Realm realm) {<br />
return new ButtonObservableValue(realm, button);<br />
}<br />
<br />
public void change(IObservable observable) {<br />
boolean value = button.getSelection();<br />
button.setSelection(!value);<br />
button.notifyListeners(SWT.Selection, null);<br />
}<br />
<br />
public Object createValue(IObservableValue observable) {<br />
return (Boolean.TRUE.equals(observable.getValue()) ? Boolean.FALSE : Boolean.TRUE);<br />
}<br />
<br />
public Object getValueType(IObservableValue observable) {<br />
return Boolean.TYPE;<br />
}<br />
}<br />
}<br />
<br />
When subclassing, because of single inheritance, you will will have to create multiple implementations to test the mutable and immutable use cases (e.g. there would need to be a ButtonMutableObservableValueTest as well to test the mutable cases). The rest of the implementation should be straightforward. The only thing we ask is that you don't depend upon API other than the constructors. Tests are public because JUnit requires them to be, not because we want to commit to them as API. Over time we would like to have the opportunity to rename, add, remove, or optimize the test methods to ensure that we're getting the best coverage as possible. Because of the issues outlined above the preferred method is creating a JUnit suite.<br />
<br />
==== JUnit suite() ====<br />
public class ButtonObservableValueTest extends TestCase {<br />
public static Test suite() {<br />
Delegate delegate = new Delegate();<br />
<br />
return new SuiteBuilder().addTests(ButtonObservableValueTest.class)<br />
.addObservableContractTest(<br />
SWTObservableValueContractTest.class, delegate)<br />
.addObservableContractTest(<br />
SWTMutableObservableValueContractTest.class, delegate)<br />
.build();<br />
}<br />
<br />
/* package */ static class Delegate extends AbstractObservableValueContractDelegate {<br />
private Shell shell;<br />
private Button button;<br />
<br />
public void setUp() {<br />
shell = new Shell();<br />
button = new Button(shell, SWT.CHECK);<br />
}<br />
<br />
public void tearDown() {<br />
shell.dispose();<br />
}<br />
<br />
public IObservableValue createObservableValue(Realm realm) {<br />
return new ButtonObservableValue(realm, button);<br />
}<br />
<br />
public void change(IObservable observable) {<br />
boolean value = button.getSelection();<br />
button.setSelection(!value);<br />
button.notifyListeners(SWT.Selection, null);<br />
}<br />
<br />
public Object createValue(IObservableValue observable) {<br />
return (Boolean.TRUE.equals(observable.getValue()) ? Boolean.FALSE : Boolean.TRUE);<br />
}<br />
<br />
public Object getValueType(IObservableValue observable) {<br />
return Boolean.TYPE;<br />
}<br />
}<br />
} <br />
<br />
By creating a suite() method you can create a custom suite of tests to run. This will allow you to run multiple TestCases from a single test eliminating the need to create multiple implementations for the mutable and immutable cases. The &lt;code&gt;SuiteBuilder&lt;/code&gt; implementation allows for a straightforward way to build these suites. The downside to building tests in this fashion is that when ran they don't contain the context of a parent class. In the JUnit view in Eclipse they are children of a junit.framework.TestSuite rather than a named test. As a way around this the failure message contains information about the context of the failure (e.g. Test class name and delegate name).</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/Conformance_TestsJFace Data Binding/Conformance Tests2007-09-30T23:06:41Z<p>Bradleyjames.gmail.com: JFace Data Binding/TCK moved to JFace Data Binding/Conformance Tests</p>
<hr />
<div>The JFace Data Binding TCK is a suite of tests and other files that allow for asserting the conformance of implementations to the abstractions provided by the library.<br />
<br />
'''The TCK is not yet available but will be soon for early adopters.'''<br />
<br />
== Observables ==<br />
The TCK provides tests for the assertion of conformance to the observable specifications. Tests are currently provided for implementations of:<br />
* IObservable<br />
* IObservableValue<br />
* IObservableCollection<br />
* IObservableList<br />
* IObservableSet<br />
<br />
Tests are broken up into mutable and immutable test cases (e.g. ObservableValueContractTest and MutableObservableValueContractTest). The reason for this is that not all implementations allow for a consumer to mutate the observable via its API. The TCK tests assert the following when appropriate:<br />
* Change events and their diffs<br />
* Realm checking<br />
* ObservableTracker.getterCalled(IObservable) invocations<br />
* Values and value types<br />
<br />
The TCK tests don't assert the observed object state. Because the observed object can be of any type and the value can be in any form this isn't something that we feel we can reliably provide. It would be more straightforward for these to remain in your own tests.<br />
<br />
=== Delegates ===<br />
In order to take advantage of the tests developers will need to create a contract delegate. The delegates allow for implementation specific details to be provided to the TCK. The IObservableContractDelegate is provided below as an example:<br />
<br />
public interface IObservableContractDelegate {<br />
/**<br />
* Notifies the delegate of the start of a test.<br />
*/<br />
public void setUp();<br />
<br />
/**<br />
* Notifies the delegate of the end of a test.<br />
*/<br />
public void tearDown();<br />
<br />
/**<br />
* Invokes an operation to set the stale state of the provided<br />
* &lt;code&gt;observable&lt;/code&gt;.<br />
* <br />
* @param observable<br />
* @param stale<br />
*/<br />
public void setStale(IObservable observable, boolean stale);<br />
<br />
/**<br />
* Creates a new observable.<br />
* <br />
* @param realm realm of the observable<br />
* @return observable<br />
*/<br />
public IObservable createObservable(Realm realm);<br />
<br />
/**<br />
* Invokes a change operation on the observable resulting in a change event<br />
* being fired from the observable.<br />
* <br />
* @param observable<br />
*/<br />
public void change(IObservable observable);<br />
}<br />
<br />
The delegate API follows the standard JUnit conventions of setUp() and tearDown(). The other methods will be invoked when necessary by the tests.<br />
<br />
The delegates provided are:<br />
* org.eclipse.jface.databinding.conformance.delegate.IObservableContractDelegate<br />
* org.eclipse.jface.databinding.conformance.delegate.IObservableValueContractDelegate<br />
* org.eclipse.jface.databinding.conformance.delegate.IObservableCollectionContractDelegate<br />
<br />
Your observable implementation will determine which delegate to construct. Abstract implementations are provided to simplify implementing a delegate.<br />
<br />
=== Integration into Tests ===<br />
Since the tests are JUnit3 tests you can integrate them into your tests in standard ways. The two most common ways are by subclassing or creating a suite.<br />
<br />
==== Subclassing ====<br />
public class ButtonObservableValueTest extends SWTObservableValueContractTest {<br />
public ButtonObservableValueTest() {<br />
super(new Delegate());<br />
}<br />
<br />
/* package */ static class Delegate extends AbstractObservableValueContractDelegate {<br />
private Shell shell;<br />
private Button button;<br />
<br />
public void setUp() {<br />
shell = new Shell();<br />
button = new Button(shell, SWT.CHECK);<br />
}<br />
<br />
public void tearDown() {<br />
shell.dispose();<br />
}<br />
<br />
public IObservableValue createObservableValue(Realm realm) {<br />
return new ButtonObservableValue(realm, button);<br />
}<br />
<br />
public void change(IObservable observable) {<br />
boolean value = button.getSelection();<br />
button.setSelection(!value);<br />
button.notifyListeners(SWT.Selection, null);<br />
}<br />
<br />
public Object createValue(IObservableValue observable) {<br />
return (Boolean.TRUE.equals(observable.getValue()) ? Boolean.FALSE : Boolean.TRUE);<br />
}<br />
<br />
public Object getValueType(IObservableValue observable) {<br />
return Boolean.TYPE;<br />
}<br />
}<br />
}<br />
<br />
When subclassing, because of single inheritance, you will will have to create multiple implementations to test the mutable and immutable use cases (e.g. there would need to be a ButtonMutableObservableValueTest as well to test the mutable cases). The rest of the implementation should be straightforward. The only thing we ask is that you don't depend upon API other than the constructors. Tests are public because JUnit requires them to be, not because we want to commit to them as API. Over time we would like to have the opportunity to rename, add, remove, or optimize the test methods to ensure that we're getting the best coverage as possible. Because of the issues outlined above the preferred method is creating a JUnit suite.<br />
<br />
==== JUnit suite() ====<br />
public class ButtonObservableValueTest extends TestCase {<br />
public static Test suite() {<br />
Delegate delegate = new Delegate();<br />
<br />
return new SuiteBuilder().addTests(ButtonObservableValueTest.class)<br />
.addObservableContractTest(<br />
SWTObservableValueContractTest.class, delegate)<br />
.addObservableContractTest(<br />
SWTMutableObservableValueContractTest.class, delegate)<br />
.build();<br />
}<br />
<br />
/* package */ static class Delegate extends AbstractObservableValueContractDelegate {<br />
private Shell shell;<br />
private Button button;<br />
<br />
public void setUp() {<br />
shell = new Shell();<br />
button = new Button(shell, SWT.CHECK);<br />
}<br />
<br />
public void tearDown() {<br />
shell.dispose();<br />
}<br />
<br />
public IObservableValue createObservableValue(Realm realm) {<br />
return new ButtonObservableValue(realm, button);<br />
}<br />
<br />
public void change(IObservable observable) {<br />
boolean value = button.getSelection();<br />
button.setSelection(!value);<br />
button.notifyListeners(SWT.Selection, null);<br />
}<br />
<br />
public Object createValue(IObservableValue observable) {<br />
return (Boolean.TRUE.equals(observable.getValue()) ? Boolean.FALSE : Boolean.TRUE);<br />
}<br />
<br />
public Object getValueType(IObservableValue observable) {<br />
return Boolean.TYPE;<br />
}<br />
}<br />
} <br />
<br />
By creating a suite() method you can create a custom suite of tests to run. This will allow you to run multiple TestCases from a single test eliminating the need to create multiple implementations for the mutable and immutable cases. The &lt;code&gt;SuiteBuilder&lt;/code&gt; implementation allows for a straightforward way to build these suites. The downside to building tests in this fashion is that when ran they don't contain the context of a parent class. In the JUnit view in Eclipse they are children of a junit.framework.TestSuite rather than a named test. As a way around this the failure message contains information about the context of the failure (e.g. Test class name and delegate name).</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/TCKJFace Data Binding/TCK2007-09-30T23:06:41Z<p>Bradleyjames.gmail.com: JFace Data Binding/TCK moved to JFace Data Binding/Conformance Tests</p>
<hr />
<div>#REDIRECT [[JFace Data Binding/Conformance Tests]]</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/Conformance_TestsJFace Data Binding/Conformance Tests2007-09-30T23:06:00Z<p>Bradleyjames.gmail.com: Added information about IObservableSet and other cleanup</p>
<hr />
<div>The JFace Data Binding TCK is a suite of tests and other files that allow for asserting the conformance of implementations to the abstractions provided by the library.<br />
<br />
'''The TCK is not yet available but will be soon for early adopters.'''<br />
<br />
== Observables ==<br />
The TCK provides tests for the assertion of conformance to the observable specifications. Tests are currently provided for implementations of:<br />
* IObservable<br />
* IObservableValue<br />
* IObservableCollection<br />
* IObservableList<br />
* IObservableSet<br />
<br />
Tests are broken up into mutable and immutable test cases (e.g. ObservableValueContractTest and MutableObservableValueContractTest). The reason for this is that not all implementations allow for a consumer to mutate the observable via its API. The TCK tests assert the following when appropriate:<br />
* Change events and their diffs<br />
* Realm checking<br />
* ObservableTracker.getterCalled(IObservable) invocations<br />
* Values and value types<br />
<br />
The TCK tests don't assert the observed object state. Because the observed object can be of any type and the value can be in any form this isn't something that we feel we can reliably provide. It would be more straightforward for these to remain in your own tests.<br />
<br />
=== Delegates ===<br />
In order to take advantage of the tests developers will need to create a contract delegate. The delegates allow for implementation specific details to be provided to the TCK. The IObservableContractDelegate is provided below as an example:<br />
<br />
public interface IObservableContractDelegate {<br />
/**<br />
* Notifies the delegate of the start of a test.<br />
*/<br />
public void setUp();<br />
<br />
/**<br />
* Notifies the delegate of the end of a test.<br />
*/<br />
public void tearDown();<br />
<br />
/**<br />
* Invokes an operation to set the stale state of the provided<br />
* &lt;code&gt;observable&lt;/code&gt;.<br />
* <br />
* @param observable<br />
* @param stale<br />
*/<br />
public void setStale(IObservable observable, boolean stale);<br />
<br />
/**<br />
* Creates a new observable.<br />
* <br />
* @param realm realm of the observable<br />
* @return observable<br />
*/<br />
public IObservable createObservable(Realm realm);<br />
<br />
/**<br />
* Invokes a change operation on the observable resulting in a change event<br />
* being fired from the observable.<br />
* <br />
* @param observable<br />
*/<br />
public void change(IObservable observable);<br />
}<br />
<br />
The delegate API follows the standard JUnit conventions of setUp() and tearDown(). The other methods will be invoked when necessary by the tests.<br />
<br />
The delegates provided are:<br />
* org.eclipse.jface.databinding.conformance.delegate.IObservableContractDelegate<br />
* org.eclipse.jface.databinding.conformance.delegate.IObservableValueContractDelegate<br />
* org.eclipse.jface.databinding.conformance.delegate.IObservableCollectionContractDelegate<br />
<br />
Your observable implementation will determine which delegate to construct. Abstract implementations are provided to simplify implementing a delegate.<br />
<br />
=== Integration into Tests ===<br />
Since the tests are JUnit3 tests you can integrate them into your tests in standard ways. The two most common ways are by subclassing or creating a suite.<br />
<br />
==== Subclassing ====<br />
public class ButtonObservableValueTest extends SWTObservableValueContractTest {<br />
public ButtonObservableValueTest() {<br />
super(new Delegate());<br />
}<br />
<br />
/* package */ static class Delegate extends AbstractObservableValueContractDelegate {<br />
private Shell shell;<br />
private Button button;<br />
<br />
public void setUp() {<br />
shell = new Shell();<br />
button = new Button(shell, SWT.CHECK);<br />
}<br />
<br />
public void tearDown() {<br />
shell.dispose();<br />
}<br />
<br />
public IObservableValue createObservableValue(Realm realm) {<br />
return new ButtonObservableValue(realm, button);<br />
}<br />
<br />
public void change(IObservable observable) {<br />
boolean value = button.getSelection();<br />
button.setSelection(!value);<br />
button.notifyListeners(SWT.Selection, null);<br />
}<br />
<br />
public Object createValue(IObservableValue observable) {<br />
return (Boolean.TRUE.equals(observable.getValue()) ? Boolean.FALSE : Boolean.TRUE);<br />
}<br />
<br />
public Object getValueType(IObservableValue observable) {<br />
return Boolean.TYPE;<br />
}<br />
}<br />
}<br />
<br />
When subclassing, because of single inheritance, you will will have to create multiple implementations to test the mutable and immutable use cases (e.g. there would need to be a ButtonMutableObservableValueTest as well to test the mutable cases). The rest of the implementation should be straightforward. The only thing we ask is that you don't depend upon API other than the constructors. Tests are public because JUnit requires them to be, not because we want to commit to them as API. Over time we would like to have the opportunity to rename, add, remove, or optimize the test methods to ensure that we're getting the best coverage as possible. Because of the issues outlined above the preferred method is creating a JUnit suite.<br />
<br />
==== JUnit suite() ====<br />
public class ButtonObservableValueTest extends TestCase {<br />
public static Test suite() {<br />
Delegate delegate = new Delegate();<br />
<br />
return new SuiteBuilder().addTests(ButtonObservableValueTest.class)<br />
.addObservableContractTest(<br />
SWTObservableValueContractTest.class, delegate)<br />
.addObservableContractTest(<br />
SWTMutableObservableValueContractTest.class, delegate)<br />
.build();<br />
}<br />
<br />
/* package */ static class Delegate extends AbstractObservableValueContractDelegate {<br />
private Shell shell;<br />
private Button button;<br />
<br />
public void setUp() {<br />
shell = new Shell();<br />
button = new Button(shell, SWT.CHECK);<br />
}<br />
<br />
public void tearDown() {<br />
shell.dispose();<br />
}<br />
<br />
public IObservableValue createObservableValue(Realm realm) {<br />
return new ButtonObservableValue(realm, button);<br />
}<br />
<br />
public void change(IObservable observable) {<br />
boolean value = button.getSelection();<br />
button.setSelection(!value);<br />
button.notifyListeners(SWT.Selection, null);<br />
}<br />
<br />
public Object createValue(IObservableValue observable) {<br />
return (Boolean.TRUE.equals(observable.getValue()) ? Boolean.FALSE : Boolean.TRUE);<br />
}<br />
<br />
public Object getValueType(IObservableValue observable) {<br />
return Boolean.TYPE;<br />
}<br />
}<br />
} <br />
<br />
By creating a suite() method you can create a custom suite of tests to run. This will allow you to run multiple TestCases from a single test eliminating the need to create multiple implementations for the mutable and immutable cases. The &lt;code&gt;SuiteBuilder&lt;/code&gt; implementation allows for a straightforward way to build these suites. The downside to building tests in this fashion is that when ran they don't contain the context of a parent class. In the JUnit view in Eclipse they are children of a junit.framework.TestSuite rather than a named test. As a way around this the failure message contains information about the context of the failure (e.g. Test class name and delegate name).</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/How_to_ContributeJFace Data Binding/How to Contribute2007-09-29T05:18:50Z<p>Bradleyjames.gmail.com: Added conformance test project to project list</p>
<hr />
<div>This page is a starting point for where to begin when wanting to contribute to the project. The goal is educate and to be as up front as possible with expectations so that the process can be as efficient as possible.<br />
{{JFace Data Binding}}<br />
== Bugs==<br />
If you find a bug log it. See the FAQ entry [[../FAQ#How_do_I_report_a_bug.3F|&quot;How to Report a Bug&quot;]]. If you find a bug that you think is a duplicate, is not a bug, etc. feel free to comment saying so. <br />
<br />
If wanting to track bug changes in JDB there are a few ways:<br />
* Via email. If you want to receive email when a bug is logged you can watch the &quot;Platform-UI-Inbox@eclipse.org&quot; user. You will receive email anytime a new bug if logged to this user or an update is made while assigned to this user. To set this up see Preferences -&gt; Email Preferences -&gt; User Watching. This will email you for all Platform UI bugs, not just JDB. Depending upon your needs this might and might not be what you're looking for.<br />
* Via Atom. You can convert any query in bugzilla to a feed that will update when a matched bug changes. To convert a search to a feed perform a search and select &quot;Feed&quot; at the bottom of the search results. This [https://bugs.eclipse.org/bugs/query.cgi?bug_file_loc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_id=&amp;bug_status=NEW&amp;bugidtype=include&amp;chfield=%5BBug%20creation%5D&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;classification=Eclipse&amp;component=UI&amp;email1=&amp;email2=&amp;emailtype1=substring&amp;emailtype2=substring&amp;field-1-0-0=classification&amp;field-1-1-0=product&amp;field-1-2-0=component&amp;field-1-3-0=bug_status&amp;field-1-4-0=short_desc&amp;field0-0-0=noop&amp;keywords=&amp;keywords_type=allwords&amp;long_desc=&amp;long_desc_type=allwordssubstr&amp;product=Platform&amp;query_format=advanced&amp;remaction=&amp;short_desc=%5BDataBinding%5D&amp;short_desc_type=allwordssubstr&amp;status_whiteboard=&amp;status_whiteboard_type=allwordssubstr&amp;type-1-0-0=anyexact&amp;type-1-1-0=anyexact&amp;type-1-2-0=anyexact&amp;type-1-3-0=anyexact&amp;type-1-4-0=allwordssubstr&amp;type0-0-0=noop&amp;value-1-0-0=Eclipse&amp;value-1-1-0=Platform&amp;value-1-2-0=UI&amp;value-1-3-0=NEW&amp;value-1-4-0=%5BDataBinding%5D&amp;value0-0-0=&amp;votes= query] will update when a new bug is logged with &quot;[DataBinding]&quot; in the summary.<br />
<br />
== Contributing Code==<br />
Whether you're wanting to fix a typo in javadoc or to implement the next whiz bang feature of JDB you'll need to know a few things before you contribute code.<br />
<br />
=== Checking out the Plug-ins===<br />
The project is comprised of the following plug-ins.<br />
* org.eclipse.core.databinding<br />
* org.eclipse.core.databinding.beans<br />
* org.eclipse.jface.databinding<br />
* org.eclipse.jface.databinding.examples<br />
* org.eclipse.jface.tests.databinding<br />
* org.eclipse.jface.tests.databinding.conformance<br />
<br />
You can check these out from CVS manually or with a [http://www.eclipse.org/eclipse/platform-ui/psf/ Project Set File]. You can import the file into Eclipse via File-&gt;Import, Team-&gt;Team Project Set. This will check out the necessary projects into your workspace. We provide Project Sets for committers and contributors and for HEAD and maintenance branches.<br />
<br />
=== Unit Testing===<br />
Testing is imperative to the health of the project. We have a significant amount of tests. The quantity of tests will keep growing as more functionality is added to the library. If you are contributing a fix or writing an enhancement it's a requirement that tests are written. If you don't write them a committer will have to and that could slow down the contribution process. <br />
<br />
There are a couple of things that you should know about our testing process:<br />
* All tests are included in org.eclipse.jface.tests.databinding.<br />
* If looking for tests for a specific class look for a class named {THECLASS}Test.java (e.g. UpdateStrategy.java -&gt; UpdateStrategyTest.java).<br />
* To run all tests see the FAQ entry [[../FAQ#How_do_I_run_the_tests.3F|&quot;How do I run the tests?&quot;]]<br />
* If you create a new TestCase make sure to add it to BindingTestSuite. Your TestCase will then be ran as part of the JFace-Data Binding Test Suite.<br />
* If you want to make a good impression write tests. This goes for any project but especially JDB.<br />
<br />
=== The Build===<br />
The Eclipse build is a bit of a mystery to newcomers. But rest assured that if you break something everyone will know about it and we will laugh at you (not really but we might tease you). If you do one thing it should be to sign up for the [https://dev.eclipse.org/mailman/listinfo/platform-releng-dev platform-releng-dev mailing list]. You'll receive emails when builds complete and when build and test failures occur. It's always good to pay extra special attention on the mornings after you make a commit or someone makes a commit on your behalf. The normal reaction to &quot;breaking the build&quot; is to log a bug, notify the platform-releng-dev list about it so that others can gauge the quality of the build, and then fix the bug. If your mail client allows it might be a good idea to setup a filter to flag anything with &quot;databinding&quot; in the message from platform-releng-dev. This will help filter out the signal from the noise.<br />
<br />
== Newsgroup==<br />
We try to be prompt and responsive on the [http://www.eclipse.org/newsportal/thread.php?group=eclipse.platform newsgroup] but there's always room for improvement. If you know the answer to a query feel free to respond.<br />
<br />
== Wiki==<br />
The wiki is open and can be edited by all. If you find a typo, a broken link, or anything that you view as a small issue feel free to fix it. If wanting to contribute a significant amount of information or create a new article we request that you [[../FAQ#How_do_I_report_a_bug.3F|log a bug]] so that we're aware of what you're contributing. This is so that we can ensure consistency structurally and in the message conveyed.<br />
<br />
For more information on our wiki editing guidelines see [[JFace Data Binding/Wiki Guidelines]].<br />
[[Category:Data Binding]][[Category:How to Contribute]]</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/User:Bradleyjames.gmail.comUser:Bradleyjames.gmail.com2007-09-09T16:43:32Z<p>Bradleyjames.gmail.com: </p>
<hr />
<div>Committer on the JFace Data Binding project.<br />
<br />
blog: [http://fire-change-event.blogspot.com http://fire-change-event.blogspot.com]<br />
<br />
blog2: [http://qseclipse.blogspot.com http://qseclipse.blogspot.com]</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/User:Bradleyjames.gmail.comUser:Bradleyjames.gmail.com2007-09-09T16:43:07Z<p>Bradleyjames.gmail.com: Added second blog link.</p>
<hr />
<div>Committer on the JFace Data Binding project.<br />
<br />
blog: [http://fire-change-event.blogspot.com http://fire-change-event.blogspot.com]<br />
blog2: [http://qseclipse.blogspot.com http://qseclipse.blogspot.com]</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_BindingJFace Data Binding2007-09-06T23:37:21Z<p>Bradleyjames.gmail.com: /* Project Status */</p>
<hr />
<div>JFace Data Binding is a multi-threaded set of abstractions that allow for automated validation and synchronization of values between objects. This is commonly used for, but not limited to, the binding of user interface components to model attributes. The core concepts behind the project are [[Observables]] and [[Binding | Bindings]]. We provide IObservable implementations for SWT, JFace, and JavaBeans but the core is void of references to these in anticipation of implementations for other projects (e.g. EMF, Swing, etc.).<br />
{{JFace Data Binding}}<br />
== Articles ==<br />
=== Concepts ===<br />
* [[/Observable|Observable]]<br />
* [[/Binding|Binding]]<br />
* [[/Converter|Converter]]<br />
* Validators<br />
* [[/Realm|Realm]]<br />
* Master Detail<br />
<br />
=== Requirements and Design ===<br />
* [[JFace Data Binding Introduction]]<br />
* [[/Original Design | Original Design Document]]<br />
* [[/Scenarios | Scenarios Document]]<br />
<br />
=== Tutorials &amp; Presentations ===<br />
* [[Media:Databinding.pdf | Dave Orme's EclipseCon 2006 Lightning Talk slides]] ''(The code in this presentation is out of date and should not be used as an example but the concepts are still relevant.)''<br />
* [https://admin.adobe.acrobat.com/_a300965365/p77464314/ JFace Data Binding Webinar]<br />
* [[Media:Databinding.zip | Dave and Boris's EclipseCon 2007 long talk and slides]]<br />
<br />
=== Miscellaneous ===<br />
* [[/FAQ | FAQ]]<br />
* [[/How to Contribute | How to Contribute]]<br />
*[[/Wiki Guidelines|Wiki Guidelines]]<br />
<br />
== Contact Us ==<br />
The [http://www.eclipse.org/newsportal/thread.php?group=eclipse.platform Platform newsgroup] is the place for discussions and questions relating to JFace Data Binding. When posting please prefix the subject with &quot;[DataBinding]&quot; to allow us to easily find posts related to the project.<br />
<br />
Design discussions and bugs are located on [https://bugs.eclipse.org/bugs/ Eclipse bugzilla] with a the values...<br />
; Classification : Eclipse <br />
; Product : Platform<br />
; Component : UI<br />
<br />
Like posts to the newsgroup when logging bugs please prefix the summary with &quot;[DataBinding]&quot; to allow for easier identification.<br />
<br />
== Getting Involved ==<br />
There are many ways to get involved with JFace Data Binding. To find out how you can contribute see [[/How to Contribute|How to Contribute]].<br />
<br />
==Project Release Status==<br />
JFace Data Binding 1.0 was releaseed with Eclipse 3.3, [[Europa Simultaneous Release | Europa]]. We're currently working on the [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=%5BDataBinding%5D&amp;classification=Eclipse&amp;product=Platform&amp;component=UI&amp;target_milestone=3.3.1&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=&amp;emailtype1=substring&amp;email1=&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0= 3.3.1 maintenance release] as well as enhancements for 3.4.<br />
<br />
[[Category:Data Binding]]</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/Template:JFace_Data_BindingTemplate:JFace Data Binding2007-09-06T23:36:11Z<p>Bradleyjames.gmail.com: Add &quot;concept&quot; and how to contribute links</p>
<hr />
<div>{| style=&quot;margin: 0 0 0.5em 1em; border: 1px solid #aaaaaa; float:right; clear:right; border-collapse:collapse;&quot; cellpadding=1<br />
|-<br />
| style=&quot;background:#ccccff; padding: 0 5px 0 5px;&quot; align=&quot;center&quot; | &lt;strong&gt;JFace Data Binding&lt;/strong&gt;<br />
|-<br />
| style=&quot;font-size: 90%; padding: 0 5px 0 5px;&quot; align=&quot;center&quot; | [[JFace Data Binding | Home]]<br />
|-<br />
| style=&quot;font-size: 90%; padding: 0 5px 0 5px;&quot; align=&quot;center&quot; | [[JFace Data Binding/How to Contribute | How to Contribute]]<br />
|-<br />
| style=&quot;font-size: 90%; padding: 0 5px 0 5px;&quot; align=&quot;center&quot; | [[JFace Data Binding/FAQ | FAQ]]<br />
|-<br />
| style=&quot;font-size: 90%; padding: 0 5px 0 5px;&quot; align=&quot;center&quot; | [[JFace Data Binding/Snippets | Snippets]]<br />
|-<br />
| style=&quot;background:#ccccff; padding: 0 5px 0 5px;&quot; align=&quot;center&quot;| Concepts<br />
|-<br />
| style=&quot;font-size: 90%; padding: 0 5px 0 5px;&quot; align=&quot;center&quot; | [[JFace Data Binding/Binding | Binding]]<br />
|-<br />
| style=&quot;font-size: 90%; padding: 0 5px 0 5px;&quot; align=&quot;center&quot; | [[JFace Data Binding/Converter | Converter]]<br />
|-<br />
| style=&quot;font-size: 90%; padding: 0 5px 0 5px;&quot; align=&quot;center&quot; | [[JFace Data Binding/Observable | Observable]]<br />
|-<br />
| style=&quot;font-size: 90%; padding: 0 5px 0 5px;&quot; align=&quot;center&quot; | [[JFace Data Binding/Realm | Realm]]<br />
|}<br />
&lt;!-- This template is used to provide a navigation bar for JFace Data Binding pages --&gt;</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/Wiki_GuidelinesJFace Data Binding/Wiki Guidelines2007-09-06T23:30:25Z<p>Bradleyjames.gmail.com: Added Side Bar section</p>
<hr />
<div>The articles contained at and under [[JFace Data Binding]] create the core documentation for the project. This article will provide guidelines for structing the documentation for the project.<br />
{{JFace Data Binding}}<br />
=Who Can Edit=<br />
Anyone is welcome to edit the articles for JFace Data Binding. Feel free to fix typos, clean up confusing text, or write new articles. If contributing a large amount of documentation it might be a good idea to log a bug letting us know of the contribution. This is not a requirement but it will help us ensure that the message is consistent and that we're keeping the structure of the site consistent.<br />
<br />
=Structure=<br />
Articles that document core concepts, code, policy, or procedure of the JFace Data Binding project should be [http://meta.wikimedia.org/wiki/Sub_pages#Enabling_in_main_name_space subpages] of the main article [[JFace Data Binding]]. In order to create a subpage append a '/' and then the new article name to the URL of the main page. MediaWiki will handle the rest. This will place a link at the top of the article back to the main article providing context. Not all articles need to be children of the main as a structured hierarchy isn't always an option (i.e. contributed tutorials, documentation of observables for a different project, etc.). If creating such a page you might want to consider adding the &quot;Data Binding&quot; category to the page.<br />
<br />
=Category=<br />
Any page related to the concept of data binding in general should be added to the [[:Category:Data Binding|Data Binding]] [http://meta.wikimedia.org/wiki/Category category]. To do this add the following to the article...<br />
&lt;nowiki&gt;[[&lt;/nowiki&gt;Category:''Data Binding'']]<br />
The category will allow for documents that aren't necessarilly part of the core documentation, or part of the article hierarchy, to be aggregated.<br />
<br />
=Side Bar=<br />
On some of the JFace Data Binding pages you'll see a side bar on the top right. This is done with the JFace Data Binding Template.<br />
<br />
&lt;nowiki&gt;{{JFace Data Binding}}&lt;/nowiki&gt;<br />
<br />
The recommendation is to put this towards the top of the page. It is provided so that we can create a feeling of a site within our documentation.<br />
[[Category:Data Binding]]</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/How_to_ContributeJFace Data Binding/How to Contribute2007-09-06T23:25:07Z<p>Bradleyjames.gmail.com: /* Wiki */</p>
<hr />
<div>This page is a starting point for where to begin when wanting to contribute to the project. The goal is educate and to be as up front as possible with expectations so that the process can be as efficient as possible.<br />
{{JFace Data Binding}}<br />
== Bugs==<br />
If you find a bug log it. See the FAQ entry [[../FAQ#How_do_I_report_a_bug.3F|&quot;How to Report a Bug&quot;]]. If you find a bug that you think is a duplicate, is not a bug, etc. feel free to comment saying so. <br />
<br />
If wanting to track bug changes in JDB there are a few ways:<br />
* Via email. If you want to receive email when a bug is logged you can watch the &quot;Platform-UI-Inbox@eclipse.org&quot; user. You will receive email anytime a new bug if logged to this user or an update is made while assigned to this user. To set this up see Preferences -&gt; Email Preferences -&gt; User Watching. This will email you for all Platform UI bugs, not just JDB. Depending upon your needs this might and might not be what you're looking for.<br />
* Via Atom. You can convert any query in bugzilla to a feed that will update when a matched bug changes. To convert a search to a feed perform a search and select &quot;Feed&quot; at the bottom of the search results. This [https://bugs.eclipse.org/bugs/query.cgi?bug_file_loc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_id=&amp;bug_status=NEW&amp;bugidtype=include&amp;chfield=%5BBug%20creation%5D&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;classification=Eclipse&amp;component=UI&amp;email1=&amp;email2=&amp;emailtype1=substring&amp;emailtype2=substring&amp;field-1-0-0=classification&amp;field-1-1-0=product&amp;field-1-2-0=component&amp;field-1-3-0=bug_status&amp;field-1-4-0=short_desc&amp;field0-0-0=noop&amp;keywords=&amp;keywords_type=allwords&amp;long_desc=&amp;long_desc_type=allwordssubstr&amp;product=Platform&amp;query_format=advanced&amp;remaction=&amp;short_desc=%5BDataBinding%5D&amp;short_desc_type=allwordssubstr&amp;status_whiteboard=&amp;status_whiteboard_type=allwordssubstr&amp;type-1-0-0=anyexact&amp;type-1-1-0=anyexact&amp;type-1-2-0=anyexact&amp;type-1-3-0=anyexact&amp;type-1-4-0=allwordssubstr&amp;type0-0-0=noop&amp;value-1-0-0=Eclipse&amp;value-1-1-0=Platform&amp;value-1-2-0=UI&amp;value-1-3-0=NEW&amp;value-1-4-0=%5BDataBinding%5D&amp;value0-0-0=&amp;votes= query] will update when a new bug is logged with &quot;[DataBinding]&quot; in the summary.<br />
<br />
== Contributing Code==<br />
Whether you're wanting to fix a typo in javadoc or to implement the next whiz bang feature of JDB you'll need to know a few things before you contribute code.<br />
<br />
=== Checking out the Plug-ins===<br />
The project is comprised of the following plug-ins.<br />
* org.eclipse.core.databinding<br />
* org.eclipse.core.databinding.beans<br />
* org.eclipse.jface.databinding<br />
* org.eclipse.jface.databinding.examples<br />
* org.eclipse.jface.tests.databinding<br />
<br />
You can check these out from CVS manually or with a [http://www.eclipse.org/eclipse/platform-ui/psf/ Project Set File]. You can import the file into Eclipse via File-&gt;Import, Team-&gt;Team Project Set. This will check out the necessary projects into your workspace. We provide Project Sets for committers and contributors and for HEAD and maintenance branches.<br />
<br />
=== Unit Testing===<br />
Testing is imperative to the health of the project. We have a significant amount of tests. The quantity of tests will keep growing as more functionality is added to the library. If you are contributing a fix or writing an enhancement it's a requirement that tests are written. If you don't write them a committer will have to and that could slow down the contribution process. <br />
<br />
There are a couple of things that you should know about our testing process:<br />
* All tests are included in org.eclipse.jface.tests.databinding.<br />
* If looking for tests for a specific class look for a class named {THECLASS}Test.java (e.g. UpdateStrategy.java -&gt; UpdateStrategyTest.java).<br />
* To run all tests see the FAQ entry [[../FAQ#How_do_I_run_the_tests.3F|&quot;How do I run the tests?&quot;]]<br />
* If you create a new TestCase make sure to add it to BindingTestSuite. Your TestCase will then be ran as part of the JFace-Data Binding Test Suite.<br />
* If you want to make a good impression write tests. This goes for any project but especially JDB.<br />
<br />
=== The Build===<br />
The Eclipse build is a bit of a mystery to newcomers. But rest assured that if you break something everyone will know about it and we will laugh at you (not really but we might tease you). If you do one thing it should be to sign up for the [https://dev.eclipse.org/mailman/listinfo/platform-releng-dev platform-releng-dev mailing list]. You'll receive emails when builds complete and when build and test failures occur. It's always good to pay extra special attention on the mornings after you make a commit or someone makes a commit on your behalf. The normal reaction to &quot;breaking the build&quot; is to log a bug, notify the platform-releng-dev list about it so that others can gauge the quality of the build, and then fix the bug. If your mail client allows it might be a good idea to setup a filter to flag anything with &quot;databinding&quot; in the message from platform-releng-dev. This will help filter out the signal from the noise.<br />
<br />
== Newsgroup==<br />
We try to be prompt and responsive on the [http://www.eclipse.org/newsportal/thread.php?group=eclipse.platform newsgroup] but there's always room for improvement. If you know the answer to a query feel free to respond.<br />
<br />
== Wiki==<br />
The wiki is open and can be edited by all. If you find a typo, a broken link, or anything that you view as a small issue feel free to fix it. If wanting to contribute a significant amount of information or create a new article we request that you [[../FAQ#How_do_I_report_a_bug.3F|log a bug]] so that we're aware of what you're contributing. This is so that we can ensure consistency structurally and in the message conveyed.<br />
<br />
For more information on our wiki editing guidelines see [[JFace Data Binding/Wiki Guidelines]].<br />
[[Category:Data Binding]]</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_BindingJFace Data Binding2007-09-06T01:20:42Z<p>Bradleyjames.gmail.com: /* Miscellaneous */</p>
<hr />
<div>JFace Data Binding is a multi-threaded set of abstractions that allow for automated validation and synchronization of values between objects. This is commonly used for, but not limited to, the binding of user interface components to model attributes. The core concepts behind the project are [[Observables]] and [[Binding | Bindings]]. We provide IObservable implementations for SWT, JFace, and JavaBeans but the core is void of references to these in anticipation of implementations for other projects (e.g. EMF, Swing, etc.).<br />
{{JFace Data Binding}}<br />
== Articles ==<br />
=== Concepts ===<br />
* [[/Observable|Observable]]<br />
* [[/Binding|Binding]]<br />
* [[/Converter|Converter]]<br />
* Validators<br />
* [[/Realm|Realm]]<br />
* Master Detail<br />
<br />
=== Requirements and Design ===<br />
* [[JFace Data Binding Introduction]]<br />
* [[/Original Design | Original Design Document]]<br />
* [[/Scenarios | Scenarios Document]]<br />
<br />
=== Tutorials &amp; Presentations ===<br />
* [[Media:Databinding.pdf | Dave Orme's EclipseCon 2006 Lightning Talk slides]] ''(The code in this presentation is out of date and should not be used as an example but the concepts are still relevant.)''<br />
* [https://admin.adobe.acrobat.com/_a300965365/p77464314/ JFace Data Binding Webinar]<br />
* [[Media:Databinding.zip | Dave and Boris's EclipseCon 2007 long talk and slides]]<br />
<br />
=== Miscellaneous ===<br />
* [[/FAQ | FAQ]]<br />
* [[/How to Contribute | How to Contribute]]<br />
*[[/Wiki Guidelines|Wiki Guidelines]]<br />
<br />
== Contact Us ==<br />
The [http://www.eclipse.org/newsportal/thread.php?group=eclipse.platform Platform newsgroup] is the place for discussions and questions relating to JFace Data Binding. When posting please prefix the subject with &quot;[DataBinding]&quot; to allow us to easily find posts related to the project.<br />
<br />
Design discussions and bugs are located on [https://bugs.eclipse.org/bugs/ Eclipse bugzilla] with a the values...<br />
; Classification : Eclipse <br />
; Product : Platform<br />
; Component : UI<br />
<br />
Like posts to the newsgroup when logging bugs please prefix the summary with &quot;[DataBinding]&quot; to allow for easier identification.<br />
<br />
== Getting Involved ==<br />
There are many ways to get involved with JFace Data Binding. To find out how you can contribute see [[/How to Contribute|How to Contribute]].<br />
<br />
== Project Status ==<br />
JFace Data Binding 1.0 was releaseed with Eclipse 3.3, [[Europa Simultaneous Release | Europa]]. We're currently working on the [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=%5BDataBinding%5D&amp;classification=Eclipse&amp;product=Platform&amp;component=UI&amp;target_milestone=3.3.1&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=&amp;emailtype1=substring&amp;email1=&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0= 3.3.1 maintenance release] as well as enhancements for 3.4.<br />
<br />
[[Category:Data Binding]]</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/Wiki_GuidelinesJFace Data Binding/Wiki Guidelines2007-09-06T01:20:02Z<p>Bradleyjames.gmail.com: New page: The articles contained at and under JFace Data Binding create the core documentation for the project. This article will provide guidelines for structing the documentation for the proj...</p>
<hr />
<div>The articles contained at and under [[JFace Data Binding]] create the core documentation for the project. This article will provide guidelines for structing the documentation for the project.<br />
<br />
=Who Can Edit=<br />
Anyone is welcome to edit the articles for JFace Data Binding. Feel free to fix typos, clean up confusing text, or write new articles. If contributing a large amount of documentation it might be a good idea to log a bug letting us know of the contribution. This is not a requirement but it will help us ensure that the message is consistent and that we're keeping the structure of the site consistent.<br />
<br />
=Structure=<br />
Articles that document core concepts, code, policy, or procedure of the JFace Data Binding project should be [http://meta.wikimedia.org/wiki/Sub_pages#Enabling_in_main_name_space subpages] of the main article [[JFace Data Binding]]. In order to create a subpage append a '/' and then the new article name to the URL of the main page. MediaWiki will handle the rest. This will place a link at the top of the article back to the main article providing context. Not all articles need to be children of the main as a structured hierarchy isn't always an option (i.e. contributed tutorials, documentation of observables for a different project, etc.). If creating such a page you might want to consider adding the &quot;Data Binding&quot; category to the page.<br />
<br />
=Category=<br />
Any page related to the concept of data binding in general should be added to the [[:Category:Data Binding|Data Binding]] [http://meta.wikimedia.org/wiki/Category category]. To do this add the following to the article...<br />
&lt;nowiki&gt;[[&lt;/nowiki&gt;Category:''Data Binding'']]<br />
The category will allow for documents that aren't necessarilly part of the core documentation, or part of the article hierarchy, to be aggregated.<br />
<br />
[[Category:Data Binding]]</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_BindingJFace Data Binding2007-09-06T00:45:08Z<p>Bradleyjames.gmail.com: Added link for 3.3.1 maintenace fixes</p>
<hr />
<div>JFace Data Binding is a multi-threaded set of abstractions that allow for automated validation and synchronization of values between objects. This is commonly used for, but not limited to, the binding of user interface components to model attributes. The core concepts behind the project are [[Observables]] and [[Binding | Bindings]]. We provide IObservable implementations for SWT, JFace, and JavaBeans but the core is void of references to these in anticipation of implementations for other projects (e.g. EMF, Swing, etc.).<br />
{{JFace Data Binding}}<br />
== Articles ==<br />
=== Concepts ===<br />
* [[/Observable|Observable]]<br />
* [[/Binding|Binding]]<br />
* [[/Converter|Converter]]<br />
* Validators<br />
* [[/Realm|Realm]]<br />
* Master Detail<br />
<br />
=== Requirements and Design ===<br />
* [[JFace Data Binding Introduction]]<br />
* [[/Original Design | Original Design Document]]<br />
* [[/Scenarios | Scenarios Document]]<br />
<br />
=== Tutorials &amp; Presentations ===<br />
* [[Media:Databinding.pdf | Dave Orme's EclipseCon 2006 Lightning Talk slides]] ''(The code in this presentation is out of date and should not be used as an example but the concepts are still relevant.)''<br />
* [https://admin.adobe.acrobat.com/_a300965365/p77464314/ JFace Data Binding Webinar]<br />
* [[Media:Databinding.zip | Dave and Boris's EclipseCon 2007 long talk and slides]]<br />
<br />
=== Miscellaneous ===<br />
* [[/FAQ | FAQ]]<br />
* [[/How to Contribute | How to Contribute]]<br />
<br />
== Contact Us ==<br />
The [http://www.eclipse.org/newsportal/thread.php?group=eclipse.platform Platform newsgroup] is the place for discussions and questions relating to JFace Data Binding. When posting please prefix the subject with &quot;[DataBinding]&quot; to allow us to easily find posts related to the project.<br />
<br />
Design discussions and bugs are located on [https://bugs.eclipse.org/bugs/ Eclipse bugzilla] with a the values...<br />
; Classification : Eclipse <br />
; Product : Platform<br />
; Component : UI<br />
<br />
Like posts to the newsgroup when logging bugs please prefix the summary with &quot;[DataBinding]&quot; to allow for easier identification.<br />
<br />
== Getting Involved ==<br />
There are many ways to get involved with JFace Data Binding. To find out how you can contribute see [[/How to Contribute|How to Contribute]].<br />
<br />
== Project Status ==<br />
JFace Data Binding 1.0 was releaseed with Eclipse 3.3, [[Europa Simultaneous Release | Europa]]. We're currently working on the [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=%5BDataBinding%5D&amp;classification=Eclipse&amp;product=Platform&amp;component=UI&amp;target_milestone=3.3.1&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=&amp;emailtype1=substring&amp;email1=&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0= 3.3.1 maintenance release] as well as enhancements for 3.4.<br />
<br />
[[Category:Data Binding]]</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_BindingJFace Data Binding2007-09-06T00:33:22Z<p>Bradleyjames.gmail.com: Updating links</p>
<hr />
<div>JFace Data Binding is a multi-threaded set of abstractions that allow for automated validation and synchronization of values between objects. This is commonly used for, but not limited to, the binding of user interface components to model attributes. The core concepts behind the project are [[Observables]] and [[Binding | Bindings]]. We provide IObservable implementations for SWT, JFace, and JavaBeans but the core is void of references to these in anticipation of implementations for other projects (e.g. EMF, Swing, etc.).<br />
{{JFace Data Binding}}<br />
== Articles ==<br />
=== Concepts ===<br />
* [[/Observable|Observable]]<br />
* [[/Binding|Binding]]<br />
* [[/Converter|Converter]]<br />
* Validators<br />
* [[/Realm|Realm]]<br />
* Master Detail<br />
<br />
=== Requirements and Design ===<br />
* [[JFace Data Binding Introduction]]<br />
* [[/Original Design | Original Design Document]]<br />
* [[/Scenarios | Scenarios Document]]<br />
<br />
=== Tutorials &amp; Presentations ===<br />
* [[Media:Databinding.pdf | Dave Orme's EclipseCon 2006 Lightning Talk slides]] ''(The code in this presentation is out of date and should not be used as an example but the concepts are still relevant.)''<br />
* [https://admin.adobe.acrobat.com/_a300965365/p77464314/ JFace Data Binding Webinar]<br />
* [[Media:Databinding.zip | Dave and Boris's EclipseCon 2007 long talk and slides]]<br />
<br />
=== Miscellaneous ===<br />
* [[/FAQ | FAQ]]<br />
* [[/How to Contribute | How to Contribute]]<br />
<br />
== Contact Us ==<br />
The [http://www.eclipse.org/newsportal/thread.php?group=eclipse.platform Platform newsgroup] is the place for discussions and questions relating to JFace Data Binding. When posting please prefix the subject with &quot;[DataBinding]&quot; to allow us to easily find posts related to the project.<br />
<br />
Design discussions and bugs are located on [https://bugs.eclipse.org/bugs/ Eclipse bugzilla] with a the values...<br />
; Classification : Eclipse <br />
; Product : Platform<br />
; Component : UI<br />
<br />
Like posts to the newsgroup when logging bugs please prefix the summary with &quot;[DataBinding]&quot; to allow for easier identification.<br />
<br />
== Getting Involved ==<br />
There are many ways to get involved with JFace Data Binding. To find out how you can contribute see [[/How to Contribute|How to Contribute]].<br />
<br />
== Project Status ==<br />
JFace Data Binding 1.0 was releaseed with Eclipse 3.3, [[Europa Simultaneous Release | Europa]]. We're currently working on the 3.3.1 maintenance release as well as enhancements for 3.4.<br />
<br />
[[Category:Data Binding]]</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/RealmJFace Data Binding/Realm2007-09-06T00:21:57Z<p>Bradleyjames.gmail.com: Realm moved to JFace Data Binding/Realm: Moving all JFace Data Binding pages to be children of the main page.</p>
<hr />
<div>{{JFace Data Binding}}<br />
Realm is the core concept of [[JFace Data Binding]] in regards to synchronization. A realm can be thought of as a special thread, or a lock, that serializes access to a set of [[Observable|observables]] in that realm. Each observable belongs to a Realm. It can only be accessed from that realm, and it will always fire change events on that realm. One important example of a realm is the SWT UI thread. Like for the SWT UI thread, you can execute code within a realm by using Realm.asyncExec(); in fact, the SWT realm implementation just delegates to Display.asyncExec(). This means that while the data binding framework can be used in a multi-threaded environment, each observable is essentially single-threaded. Java bean observables implement this contract on the observable side, but don't require it on the Java beans side: Even if a bean fires a PropertyChangeEvent on a different thread, the change events originating from the observable will happen within its realm. To bridge between observables in different realms, use a data binding context - you can bind two observables even if they belong to different realms and the bindings take care of this for you by using Realm.asyncExec() where necessary.<br />
<br />
== Unit Testing ==<br />
When writing unit tests for observables or bindings it is difficult to set the default Realm without wrapping the test code in a &lt;code&gt;Runnable&lt;/code&gt; and invoking &lt;code&gt;Realm.runWithDefault(Realm realm, Runnable runnable)&lt;/code&gt;. The following implementation can be used as a stub Realm for unit testing purposes and fits into the &lt;code&gt;setUp()&lt;/code&gt; and &lt;code&gt;tearDown()&lt;/code&gt; testing paradigm.<br />
<br />
/**<br />
* Simple realm implementation that will set itself as default when constructed. Invoke<br />
* {@link #dispose()} to remove the realm from being the default. Does not support asyncExec(...).<br />
*/<br />
public class DefaultRealm extends Realm {<br />
private Realm previousRealm;<br />
<br />
public DefaultRealm() {<br />
previousRealm = super.setDefault(this);<br />
}<br />
<br />
/**<br />
* @return always returns &lt;code&gt;true&lt;/code&gt;<br />
*/<br />
public boolean isCurrent() {<br />
return true;<br />
}<br />
<br />
protected void syncExec(Runnable runnable) {<br />
runnable.run();<br />
}<br />
<br />
/**<br />
* @throws UnsupportedOperationException<br />
*/<br />
public void asyncExec(Runnable runnable) {<br />
throw new UnsupportedOperationException(&quot;asyncExec is unsupported&quot;);<br />
}<br />
<br />
/**<br />
* Removes the realm from being the current and sets the previous realm to the default.<br />
*/<br />
public void dispose() {<br />
if (getDefault() == this) {<br />
setDefault(previousRealm);<br />
}<br />
}<br />
}<br />
<br />
public class SampleTestCase extends TestCase {<br />
private DefaultRealm realm;<br />
<br />
/**<br />
* Creates a new default realm for every test.<br />
*/<br />
protected void setUp() throws Exception {<br />
super.setUp();<br />
realm = new DefaultRealm();<br />
}<br />
<br />
/**<br />
* Removes the default realm.<br />
*/<br />
protected void tearDown() throws Exception {<br />
super.tearDown();<br />
realm.dispose();<br />
}<br />
}<br />
<br />
[[Category:Data Binding]]</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/RealmRealm2007-09-06T00:21:57Z<p>Bradleyjames.gmail.com: Realm moved to JFace Data Binding/Realm: Moving all JFace Data Binding pages to be children of the main page.</p>
<hr />
<div>#REDIRECT [[JFace Data Binding/Realm]]</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/ConverterJFace Data Binding/Converter2007-09-06T00:21:21Z<p>Bradleyjames.gmail.com: Converter moved to JFace Data Binding/Converter: Moving all JFace Data Binding pages to be children of the main page.</p>
<hr />
<div>In [[JFace Data Binding]] converters are used to convert from one value type to another.<br />
{{JFace Data Binding}}<br />
Converters, implementations of &lt;code&gt;org.eclipse.core.databinding.conversion.IConverter&lt;/code&gt;, are a basic yet core part of the binding pipeline. They allow for the conversion between data types. This conversion can be as basic as converting from a primitive (e.g. boolean.class) to a boxed type (e.g. Boolean.class) or as complex as converting a String to an int.<br />
<br />
== Implementation Design Principles ==<br />
# It's best for the converter to be immutable. This will allow for greater reuse of the instance especially across threads.<br />
# Synchronize during convert(...) if necessary. A good example of this is using &lt;code&gt;com.ibm.icu.text.NumberFormat&lt;/code&gt; in a converter. NumberFormat expects to be externally synchronized as the state of NumberFormat changes during formatting and parsing. In order to be used across threads access to the internal NumberFormat must be synchronized.<br />
# If the converter is converting to a primitive from an object ensure null is handled.<br />
<br />
[[Category:Data Binding]]</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/ConverterConverter2007-09-06T00:21:21Z<p>Bradleyjames.gmail.com: Converter moved to JFace Data Binding/Converter: Moving all JFace Data Binding pages to be children of the main page.</p>
<hr />
<div>#REDIRECT [[JFace Data Binding/Converter]]</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/BindingJFace Data Binding/Binding2007-09-06T00:20:20Z<p>Bradleyjames.gmail.com: Binding moved to JFace Data Binding/Binding: Moving all JFace Data Binding pages to be children of the main page.</p>
<hr />
<div>Bindings synchronize the values of 2 [[Observable | observables]] in [[JFace Data Binding]]. The synchronization process is comprised of phases of validation and conversion. The specific phases available are dependant upon the type of binding.<br />
{{JFace Data Binding}}<br />
== Value Bindings ==<br />
A value binding binds two &lt;code&gt;IObservableValue&lt;/code&gt; instances. The order of phases are:<br />
=== Validate After Get ===<br />
Validation of the value before conversion. This phase can be used to ensure that conversion will succeed.<br />
=== Convert ===<br />
Converts the value to the expected type.<br />
=== Validate After Convert ===<br />
Validates the converted value.<br />
=== Validate Before Set ===<br />
Validates before setting the value. The only difference between 'before set' and 'after convert' is a conceptual one. Before set can be used to perform expensive validation that should be deferred until the value is copied to the model. This comes in handy in a dialog setting where validation should occur before the changes are committed.<br />
=== Set Value ===<br />
The value is set on the opposite observable. This stage is exposed in &lt;code&gt;UpdateValueStrategy&lt;/code&gt; to allow the consumer to persist changes when the value is set.<br />
<br />
== List Bindings ==<br />
A list binding binds two &lt;code&gt;IObservableList&lt;/code&gt; instances. The order of phases are:<br />
=== Convert ===<br />
Convert the value to the expected type.<br />
=== Add/Remove ===<br />
Update the opposite observable with the change.<br />
<br />
[[Category:Data Binding]]</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/BindingBinding2007-09-06T00:20:20Z<p>Bradleyjames.gmail.com: Binding moved to JFace Data Binding/Binding: Moving all JFace Data Binding pages to be children of the main page.</p>
<hr />
<div>#REDIRECT [[JFace Data Binding/Binding]]</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/ObservableJFace Data Binding/Observable2007-09-06T00:19:14Z<p>Bradleyjames.gmail.com: Observable moved to JFace Data Binding/Observable: Moving all JFace Data Binding pages to be children of the main page.</p>
<hr />
<div>Observables are one of the key abstractions provided by [[JFace Data Binding]] and are an implementation of the [http://en.wikipedia.org/wiki/Observer_pattern Observer pattern]. They provide a common abstraction for observing changes in objects.<br />
{{JFace Data Binding}}<br />
== Core Interfaces of Interest ==<br />
* IObservable - super-interface of all observables, allows to listen for generic change events<br />
* IObservableValue - has getValue(), setValue(), and allows to listen for value change events<br />
* IVetoableValue - inherits from IObservableValue, and allows to listen for before-change events<br />
* IObservableCollection - extends java.util.Collection and IObservable<br />
* IObservableList - extends java.util.List and IObservableCollection, and allows to listen for incremental list change events<br />
* IObservableSet - extends java.util.Set and IObservableCollection, and allows to listen for incremental set change events<br />
* IObservableMap - extends java.util.Map and IObservable, and allows to listen for incremental map change events<br />
<br />
== Implementation Design Principles ==<br />
# An observable must remove listeners on the observed when disposed. For example if you registered selection listeners on a widget when the observable was constructed it must remove these on dispose of the observable.<br />
# An observable should fire change events when the value changes if at all possible. This means when the value changes in the object being observed or when the value is set on the observable. One thing to look out for is firing multiple change events when this occurs. A use case where this arises is a widget that fires change events when the value is set programmatically (e.g. Text.setText(...)). In these use cases an 'updating' flag is normally employed.<br />
# Not all observables fire change events when the state of its underlying object changes, but they do fire a change event if the change goes through the observable's setter. An example of this is Control.setEnabled(...) in SWT. If the object being observed doesn't fire change events when the value is set programmatically the observable cannot observe programmatic changes in the observed object. In these use cases it still pays to have the abstraction for get/set value but when coding against such observables it's good to be aware of this behavior. Because of this it's good to always set the value on the observable to ensure that change events are fired.<br />
# In an observable when retrieving the value always retrieve it from the observed object. Don't cache the value in the observable if possible. Caching can cause issues if there's potential for this state to get out of sync like in the Control.setEnabled(...) use case mentioned above.<br />
# If the observable is an &lt;code&gt;IObservableValue&lt;/code&gt; and the type of the attribute is a primitive use the primitive class (e.g. Boolean.TYPE or boolean.class) rather than the boxed type (e.g. Boolean.class) even though when get/setValue(...) is invoked the boxed type will be returned. By using the primitive the observable will be able to convey that the value cannot be null. This allows for better control in the validation and conversion phases of binding.<br />
<br />
== @See ==<br />
[[Realm]] for how observables can be accessed in a multi-threaded environment.<br />
<br />
[[Category:Data Binding]]</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/ObservableObservable2007-09-06T00:19:14Z<p>Bradleyjames.gmail.com: Observable moved to JFace Data Binding/Observable: Moving all JFace Data Binding pages to be children of the main page.</p>
<hr />
<div>#REDIRECT [[JFace Data Binding/Observable]]</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/Category_talk:TemplatesCategory talk:Templates2007-08-27T18:36:43Z<p>Bradleyjames.gmail.com: Commented on how to find all templates</p>
<hr />
<div>== All Templates==<br />
FYI, all templates can be found by going to the &quot;All pages&quot; special page and selecting [http://wiki.eclipse.org/index.php?title=Special%3AAllpages&amp;from=&amp;namespace=10 templates].<br />
<br />
--[[User:Bradleyjames.gmail.com|Bradleyjames.gmail.com]] 14:36, 27 August 2007 (EDT)</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/How_to_ContributeJFace Data Binding/How to Contribute2007-08-26T22:49:10Z<p>Bradleyjames.gmail.com: </p>
<hr />
<div>This page is a starting point for where to begin when wanting to contribute to the project. The goal is educate and to be as up front as possible with expectations so that the process can be as efficient as possible.<br />
{{JFace Data Binding}}<br />
== Bugs==<br />
If you find a bug log it. See the FAQ entry [[../FAQ#How_do_I_report_a_bug.3F|&quot;How to Report a Bug&quot;]]. If you find a bug that you think is a duplicate, is not a bug, etc. feel free to comment saying so. <br />
<br />
If wanting to track bug changes in JDB there are a few ways:<br />
* Via email. If you want to receive email when a bug is logged you can watch the &quot;Platform-UI-Inbox@eclipse.org&quot; user. You will receive email anytime a new bug if logged to this user or an update is made while assigned to this user. To set this up see Preferences -&gt; Email Preferences -&gt; User Watching. This will email you for all Platform UI bugs, not just JDB. Depending upon your needs this might and might not be what you're looking for.<br />
* Via Atom. You can convert any query in bugzilla to a feed that will update when a matched bug changes. To convert a search to a feed perform a search and select &quot;Feed&quot; at the bottom of the search results. This [https://bugs.eclipse.org/bugs/query.cgi?bug_file_loc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_id=&amp;bug_status=NEW&amp;bugidtype=include&amp;chfield=%5BBug%20creation%5D&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;classification=Eclipse&amp;component=UI&amp;email1=&amp;email2=&amp;emailtype1=substring&amp;emailtype2=substring&amp;field-1-0-0=classification&amp;field-1-1-0=product&amp;field-1-2-0=component&amp;field-1-3-0=bug_status&amp;field-1-4-0=short_desc&amp;field0-0-0=noop&amp;keywords=&amp;keywords_type=allwords&amp;long_desc=&amp;long_desc_type=allwordssubstr&amp;product=Platform&amp;query_format=advanced&amp;remaction=&amp;short_desc=%5BDataBinding%5D&amp;short_desc_type=allwordssubstr&amp;status_whiteboard=&amp;status_whiteboard_type=allwordssubstr&amp;type-1-0-0=anyexact&amp;type-1-1-0=anyexact&amp;type-1-2-0=anyexact&amp;type-1-3-0=anyexact&amp;type-1-4-0=allwordssubstr&amp;type0-0-0=noop&amp;value-1-0-0=Eclipse&amp;value-1-1-0=Platform&amp;value-1-2-0=UI&amp;value-1-3-0=NEW&amp;value-1-4-0=%5BDataBinding%5D&amp;value0-0-0=&amp;votes= query] will update when a new bug is logged with &quot;[DataBinding]&quot; in the summary.<br />
<br />
== Contributing Code==<br />
Whether you're wanting to fix a typo in javadoc or to implement the next whiz bang feature of JDB you'll need to know a few things before you contribute code.<br />
<br />
=== Checking out the Plug-ins===<br />
The project is comprised of the following plug-ins.<br />
* org.eclipse.core.databinding<br />
* org.eclipse.core.databinding.beans<br />
* org.eclipse.jface.databinding<br />
* org.eclipse.jface.databinding.examples<br />
* org.eclipse.jface.tests.databinding<br />
<br />
You can check these out from CVS manually or with a [http://www.eclipse.org/eclipse/platform-ui/psf/ Project Set File]. You can import the file into Eclipse via File-&gt;Import, Team-&gt;Team Project Set. This will check out the necessary projects into your workspace. We provide Project Sets for committers and contributors and for HEAD and maintenance branches.<br />
<br />
=== Unit Testing===<br />
Testing is imperative to the health of the project. We have a significant amount of tests. The quantity of tests will keep growing as more functionality is added to the library. If you are contributing a fix or writing an enhancement it's a requirement that tests are written. If you don't write them a committer will have to and that could slow down the contribution process. <br />
<br />
There are a couple of things that you should know about our testing process:<br />
* All tests are included in org.eclipse.jface.tests.databinding.<br />
* If looking for tests for a specific class look for a class named {THECLASS}Test.java (e.g. UpdateStrategy.java -&gt; UpdateStrategyTest.java).<br />
* To run all tests see the FAQ entry [[../FAQ#How_do_I_run_the_tests.3F|&quot;How do I run the tests?&quot;]]<br />
* If you create a new TestCase make sure to add it to BindingTestSuite. Your TestCase will then be ran as part of the JFace-Data Binding Test Suite.<br />
* If you want to make a good impression write tests. This goes for any project but especially JDB.<br />
<br />
=== The Build===<br />
The Eclipse build is a bit of a mystery to newcomers. But rest assured that if you break something everyone will know about it and we will laugh at you (not really but we might tease you). If you do one thing it should be to sign up for the [https://dev.eclipse.org/mailman/listinfo/platform-releng-dev platform-releng-dev mailing list]. You'll receive emails when builds complete and when build and test failures occur. It's always good to pay extra special attention on the mornings after you make a commit or someone makes a commit on your behalf. The normal reaction to &quot;breaking the build&quot; is to log a bug, notify the platform-releng-dev list about it so that others can gauge the quality of the build, and then fix the bug. If your mail client allows it might be a good idea to setup a filter to flag anything with &quot;databinding&quot; in the message from platform-releng-dev. This will help filter out the signal from the noise.<br />
<br />
== Newsgroup==<br />
We try to be prompt and responsive on the [http://www.eclipse.org/newsportal/thread.php?group=eclipse.platform newsgroup] but there's always room for improvement. If you know the answer to a query feel free to respond.<br />
<br />
== Wiki==<br />
The wiki is open and can be edited by all. If you find a typo, a broken link, or anything that you view as a small issue feel free to fix it. If wanting to contribute a significant amount of information or create a new article we request that you [[../FAQ#How_do_I_report_a_bug.3F|log a bug]] so that we're aware of what you're contributing. This is so that we can ensure consistency structurally and in the message conveyed.<br />
[[Category:Data Binding]]</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/FAQJFace Data Binding/FAQ2007-08-26T22:47:48Z<p>Bradleyjames.gmail.com: /* How do I run the tests? */</p>
<hr />
<div>{{JFace Data Binding}}<br />
=== Does Data Binding depend upon Eclipse? ===<br />
The core Data Binding plug-in only depends upon org.eclipse.equinox.common and no other parts of Eclipse. There are parts of Data Binding that depend upon SWT/JFace but these have been broken out into a separate plug-in, org.eclipse.jface.databinding. For a discussion of why the core depends upon equinox common see {{bug comment|153630|9}}.<br />
<br />
=== Does Data Binding depend upon SWT? ===<br />
No. Data Binding is meant to be UI toolkit agnostic and more specifically UI agnostic. There is default support for SWT and JFace but this is in the org.eclipse.jface.databinding project which is separate from the core Data Binding APIs that live in org.eclipse.core.databinding. For background and when the separation occurred in see {{bug|153630}}.<br />
<br />
=== How do I report a bug? ===<br />
On the [https://bugs.eclipse.org/bugs Eclipse bugzilla] log a bug to Eclipse &gt; Platform &gt; UI with &quot;[DataBinding]&quot; in the summary.<br />
<br />
=== When will the public API be ready? ===<br />
The majority of refactorings have occurred. We have few planned before [http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_3.html 3.3M6] (API freeze) but we still reserve the right tweak the API as we see fit until then. The 1.0 version will be a part of Eclipse 3.3. (Technically, it will be version 1.1, because version 1.0 of data binding shipped with Eclipse 3.2.) To view the plan item for this see {{bug|154132}}.<br />
<br />
=== Where can I ask a question? ===<br />
You can ask questions on the [http://www.eclipse.org/newsportal/thread.php?group=eclipse.platform Eclipse Platform newsgroup]. When you post please prefix the title with &quot;[DataBinding]&quot;.<br />
<br />
=== How do I bind to the ValidationError of a Binding or DataBindingContext? ===<br />
See [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.examples.databinding/src/org/eclipse/jface/examples/databinding/snippets/Snippet004DataBindingContextErrorLabel.java?rev=HEAD&amp;content-type=text/vnd.viewcvs-markup snippet 004].<br />
<br />
=== How do I run the tests? ===<br />
The main JUnit Test Suite is contained in the org.eclipse.jface.tests.databinding project. This project contributes the &quot;JFace-Data Binding Test Suite&quot; to the IDE. When invoked this suite will run all tests.<br />
<br />
Steps:<br />
# Ensure the org.eclipse.jface.tests.databinding project is in your workspace.<br />
# Open the Run Dialog (Run-&gt;Open Run Dialog...).<br />
# Expand the &quot;JUnit Plug-in Test&quot; entry.<br />
# Select the &quot;JFace-Data Binding Test Suite&quot; entry and select &quot;Run&quot;.<br />
<br />
=== Where can I get the plugins? ===<br />
The JFace Data Binding plug-ins can be found in any of the following distributions on the Eclipse [http://download.eclipse.org/eclipse/downloads/ download page]:<br />
* Eclipse SDK<br />
* RCP Runtime/SDK<br />
* Platform Runtime/SDK<br />
<br />
Just select the desired build (e.g. stable, integration, nightly) and download one of the above distributions.<br />
<br />
=== Where can I find examples of how to use data binding? ===<br />
The [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.examples.databinding/ org.eclipse.jface.examples.databinding project] contains [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.examples.databinding/src/org/eclipse/jface/examples/databinding/snippets/ snippets] that demonstrate some of the more common usages of the API.<br />
<br />
=== Can JFace Data Binding run against Eclipse 3.2.x? ===<br />
Yes, but depending upon your needs you might need to take an extra step. The 1.0 version of JDB does not depend upon Eclipse 3.3 APIs. But the org.eclipse.jface.databinding plug-in distributed by Eclipse will only run against Eclipse 3.3. The distributions of org.eclipse.core.databinding and org.eclipse.core.databinding.beans will run just fine against Eclipse 3.2.x. If wanting to run org.eclipse.jface.databinding against Eclipse 3.2.x you'll need to build it from source against your target platform. For more information as to why this is necessary see {{bug|177476}}.<br />
<br />
[[Category:FAQ]]<br />
[[Category:Data Binding]]</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/How_to_ContributeJFace Data Binding/How to Contribute2007-08-26T22:37:38Z<p>Bradleyjames.gmail.com: /* Bugs */</p>
<hr />
<div>This page is a starting point for where to begin when wanting to contribute to the project. The goal is educate and to be as up front as possible with expectations so that the process can be as efficient as possible.<br />
<br />
== Bugs==<br />
If you find a bug log it. See the FAQ entry [[../FAQ#How_do_I_report_a_bug.3F|&quot;How to Report a Bug&quot;]]. If you find a bug that you think is a duplicate, is not a bug, etc. feel free to comment saying so. <br />
<br />
If wanting to track bug changes in JDB there are a few ways:<br />
* Via email. If you want to receive email when a bug is logged you can watch the &quot;Platform-UI-Inbox@eclipse.org&quot; user. You will receive email anytime a new bug if logged to this user or an update is made while assigned to this user. To set this up see Preferences -&gt; Email Preferences -&gt; User Watching. This will email you for all Platform UI bugs, not just JDB. Depending upon your needs this might and might not be what you're looking for.<br />
* Via Atom. You can convert any query in bugzilla to a feed that will update when a matched bug changes. To convert a search to a feed perform a search and select &quot;Feed&quot; at the bottom of the search results. This [https://bugs.eclipse.org/bugs/query.cgi?bug_file_loc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_id=&amp;bug_status=NEW&amp;bugidtype=include&amp;chfield=%5BBug%20creation%5D&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;classification=Eclipse&amp;component=UI&amp;email1=&amp;email2=&amp;emailtype1=substring&amp;emailtype2=substring&amp;field-1-0-0=classification&amp;field-1-1-0=product&amp;field-1-2-0=component&amp;field-1-3-0=bug_status&amp;field-1-4-0=short_desc&amp;field0-0-0=noop&amp;keywords=&amp;keywords_type=allwords&amp;long_desc=&amp;long_desc_type=allwordssubstr&amp;product=Platform&amp;query_format=advanced&amp;remaction=&amp;short_desc=%5BDataBinding%5D&amp;short_desc_type=allwordssubstr&amp;status_whiteboard=&amp;status_whiteboard_type=allwordssubstr&amp;type-1-0-0=anyexact&amp;type-1-1-0=anyexact&amp;type-1-2-0=anyexact&amp;type-1-3-0=anyexact&amp;type-1-4-0=allwordssubstr&amp;type0-0-0=noop&amp;value-1-0-0=Eclipse&amp;value-1-1-0=Platform&amp;value-1-2-0=UI&amp;value-1-3-0=NEW&amp;value-1-4-0=%5BDataBinding%5D&amp;value0-0-0=&amp;votes= query] will update when a new bug is logged with &quot;[DataBinding]&quot; in the summary.<br />
<br />
== Contributing Code==<br />
Whether you're wanting to fix a typo in javadoc or to implement the next whiz bang feature of JDB you'll need to know a few things before you contribute code.<br />
<br />
=== Checking out the Plug-ins===<br />
The project is comprised of the following plug-ins.<br />
* org.eclipse.core.databinding<br />
* org.eclipse.core.databinding.beans<br />
* org.eclipse.jface.databinding<br />
* org.eclipse.jface.databinding.examples<br />
* org.eclipse.jface.tests.databinding<br />
<br />
You can check these out from CVS manually or with a [http://www.eclipse.org/eclipse/platform-ui/psf/ Project Set File]. You can import the file into Eclipse via File-&gt;Import, Team-&gt;Team Project Set. This will check out the necessary projects into your workspace. We provide Project Sets for committers and contributors and for HEAD and maintenance branches.<br />
<br />
=== Unit Testing===<br />
Testing is imperative to the health of the project. We have a significant amount of tests. The quantity of tests will keep growing as more functionality is added to the library. If you are contributing a fix or writing an enhancement it's a requirement that tests are written. If you don't write them a committer will have to and that could slow down the contribution process. <br />
<br />
There are a couple of things that you should know about our testing process:<br />
* All tests are included in org.eclipse.jface.tests.databinding.<br />
* If looking for tests for a specific class look for a class named {THECLASS}Test.java (e.g. UpdateStrategy.java -&gt; UpdateStrategyTest.java).<br />
* To run all tests see the FAQ entry [[../FAQ#How_do_I_run_the_tests.3F|&quot;How do I run the tests?&quot;]]<br />
* If you create a new TestCase make sure to add it to BindingTestSuite. Your TestCase will then be ran as part of the JFace-Data Binding Test Suite.<br />
* If you want to make a good impression write tests. This goes for any project but especially JDB.<br />
<br />
=== The Build===<br />
The Eclipse build is a bit of a mystery to newcomers. But rest assured that if you break something everyone will know about it and we will laugh at you (not really but we might tease you). If you do one thing it should be to sign up for the [https://dev.eclipse.org/mailman/listinfo/platform-releng-dev platform-releng-dev mailing list]. You'll receive emails when builds complete and when build and test failures occur. It's always good to pay extra special attention on the mornings after you make a commit or someone makes a commit on your behalf. The normal reaction to &quot;breaking the build&quot; is to log a bug, notify the platform-releng-dev list about it so that others can gauge the quality of the build, and then fix the bug. If your mail client allows it might be a good idea to setup a filter to flag anything with &quot;databinding&quot; in the message from platform-releng-dev. This will help filter out the signal from the noise.<br />
<br />
== Newsgroup==<br />
We try to be prompt and responsive on the [http://www.eclipse.org/newsportal/thread.php?group=eclipse.platform newsgroup] but there's always room for improvement. If you know the answer to a query feel free to respond.<br />
<br />
== Wiki==<br />
The wiki is open and can be edited by all. If you find a typo, a broken link, or anything that you view as a small issue feel free to fix it. If wanting to contribute a significant amount of information or create a new article we request that you [[../FAQ#How_do_I_report_a_bug.3F|log a bug]] so that we're aware of what you're contributing. This is so that we can ensure consistency structurally and in the message conveyed.</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_BindingJFace Data Binding2007-08-25T17:51:22Z<p>Bradleyjames.gmail.com: Linked to How to Contribute</p>
<hr />
<div>JFace Data Binding is a multi-threaded set of abstractions that allow for automated validation and synchronization of values between objects. This is commonly used for, but not limited to, the binding of user interface components to model attributes. The core concepts behind the project are [[Observables]] and [[Binding | Bindings]]. We provide IObservable implementations for SWT, JFace, and JavaBeans but the core is void of references to these in anticipation of implementations for other projects (e.g. EMF, Swing, etc.).<br />
{{JFace Data Binding}}<br />
== Articles ==<br />
=== Concepts ===<br />
* [[Observables]]<br />
* [[Binding | Bindings]]<br />
* [[Converters]]<br />
* Validators<br />
* [[Realm|Realms]]<br />
* Master Detail<br />
<br />
=== Requirements and Design ===<br />
* [[JFace Data Binding Introduction]]<br />
* [[/Original Design | Original Design Document]]<br />
* [[/Scenarios | Scenarios Document]]<br />
<br />
=== Tutorials &amp; Presentations ===<br />
* [[Media:Databinding.pdf | Dave Orme's EclipseCon 2006 Lightning Talk slides]] ''(The code in this presentation is out of date and should not be used as an example but the concepts are still relevant.)''<br />
* [https://admin.adobe.acrobat.com/_a300965365/p77464314/ JFace Data Binding Webinar]<br />
* [[Media:Databinding.zip | Dave and Boris's EclipseCon 2007 long talk and slides]]<br />
<br />
=== Miscellaneous ===<br />
* [[/FAQ | FAQ]]<br />
* [[/How to Contribute | How to Contribute]]<br />
<br />
== Contact Us ==<br />
The [http://www.eclipse.org/newsportal/thread.php?group=eclipse.platform Platform newsgroup] is the place for discussions and questions relating to JFace Data Binding. When posting please prefix the subject with &quot;[DataBinding]&quot; to allow us to easily find posts related to the project.<br />
<br />
Design discussions and bugs are located on [https://bugs.eclipse.org/bugs/ Eclipse bugzilla] with a the values...<br />
; Classification : Eclipse <br />
; Product : Platform<br />
; Component : UI<br />
<br />
Like posts to the newsgroup when logging bugs please prefix the summary with &quot;[DataBinding]&quot; to allow for easier identification.<br />
<br />
== Getting Involved ==<br />
There are many ways to get involved with JFace Data Binding. To find out how you can contribute see [[/How to Contribute|How to Contribute]].<br />
<br />
== Project Status ==<br />
JFace Data Binding 1.0 was releaseed with Eclipse 3.3, [[Europa Simultaneous Release | Europa]]. We're currently working on the 3.3.1 maintenance release as well as enhancements for 3.4.<br />
<br />
[[Category:Data Binding]]</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/How_to_ContributeJFace Data Binding/How to Contribute2007-08-25T16:47:47Z<p>Bradleyjames.gmail.com: Added how to contribute via bugzilla, the newsgroup, and the wiki</p>
<hr />
<div>This page is a starting point for where to begin when wanting to contribute to the project. The goal is educate and to be as up front as possible with expectations so that the process can be as efficient as possible.<br />
<br />
== Bugs==<br />
If you find a bug log it. See the FAQ entry [[../FAQ#How_do_I_report_a_bug.3F|&quot;How to Report a Bug&quot;]]. If you find a bug that you think is a duplicate, is not a bug, etc. feel free to comment saying so. <br />
<br />
There are multiple ways to track changes in JDB bugs:<br />
* Via email. If you want to receive email when a bug is logged you can watch the &quot;Platform-UI-Inbox@eclipse.org&quot; user. You will receive email anytime a new bug if logged to this user or an update is made while assigned to this user. To set this up see Preferences -&gt; Email Preferences -&gt; User Watching. This will email you for all Platform UI bugs, not just JDB. Depending upon your needs this might and might not be what you're looking for.<br />
* Via Atom. You can convert any query in bugzilla to a feed that will update when a matched bug changes. To convert a search to a feed perform a search and select &quot;Feed&quot; at the bottom of the search results. This [https://bugs.eclipse.org/bugs/query.cgi?bug_file_loc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_id=&amp;bug_status=NEW&amp;bugidtype=include&amp;chfield=%5BBug%20creation%5D&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;classification=Eclipse&amp;component=UI&amp;email1=&amp;email2=&amp;emailtype1=substring&amp;emailtype2=substring&amp;field-1-0-0=classification&amp;field-1-1-0=product&amp;field-1-2-0=component&amp;field-1-3-0=bug_status&amp;field-1-4-0=short_desc&amp;field0-0-0=noop&amp;keywords=&amp;keywords_type=allwords&amp;long_desc=&amp;long_desc_type=allwordssubstr&amp;product=Platform&amp;query_format=advanced&amp;remaction=&amp;short_desc=%5BDataBinding%5D&amp;short_desc_type=allwordssubstr&amp;status_whiteboard=&amp;status_whiteboard_type=allwordssubstr&amp;type-1-0-0=anyexact&amp;type-1-1-0=anyexact&amp;type-1-2-0=anyexact&amp;type-1-3-0=anyexact&amp;type-1-4-0=allwordssubstr&amp;type0-0-0=noop&amp;value-1-0-0=Eclipse&amp;value-1-1-0=Platform&amp;value-1-2-0=UI&amp;value-1-3-0=NEW&amp;value-1-4-0=%5BDataBinding%5D&amp;value0-0-0=&amp;votes= query] will update when a new bug is logged with &quot;[DataBinding]&quot; in the summary.<br />
<br />
== Contributing Code==<br />
Whether you're wanting to fix a typo in javadoc or to implement the next whiz bang feature of JDB you'll need to know a few things before you contribute code.<br />
<br />
=== Checking out the Plug-ins===<br />
The project is comprised of the following plug-ins.<br />
* org.eclipse.core.databinding<br />
* org.eclipse.core.databinding.beans<br />
* org.eclipse.jface.databinding<br />
* org.eclipse.jface.databinding.examples<br />
* org.eclipse.jface.tests.databinding<br />
<br />
You can check these out from CVS manually or with a [http://www.eclipse.org/eclipse/platform-ui/psf/ Project Set File]. You can import the file into Eclipse via File-&gt;Import, Team-&gt;Team Project Set. This will check out the necessary projects into your workspace. We provide Project Sets for committers and contributors and for HEAD and maintenance branches.<br />
<br />
=== Unit Testing===<br />
Testing is imperative to the health of the project. We have a significant amount of tests. The quantity of tests will keep growing as more functionality is added to the library. If you are contributing a fix or writing an enhancement it's a requirement that tests are written. If you don't write them a committer will have to and that could slow down the contribution process. <br />
<br />
There are a couple of things that you should know about our testing process:<br />
* All tests are included in org.eclipse.jface.tests.databinding.<br />
* If looking for tests for a specific class look for a class named {THECLASS}Test.java (e.g. UpdateStrategy.java -&gt; UpdateStrategyTest.java).<br />
* To run all tests see the FAQ entry [[../FAQ#How_do_I_run_the_tests.3F|&quot;How do I run the tests?&quot;]]<br />
* If you create a new TestCase make sure to add it to BindingTestSuite. Your TestCase will then be ran as part of the JFace-Data Binding Test Suite.<br />
* If you want to make a good impression write tests. This goes for any project but especially JDB.<br />
<br />
=== The Build===<br />
The Eclipse build is a bit of a mystery to newcomers. But rest assured that if you break something everyone will know about it and we will laugh at you (not really but we might tease you). If you do one thing it should be to sign up for the [https://dev.eclipse.org/mailman/listinfo/platform-releng-dev platform-releng-dev mailing list]. You'll receive emails when builds complete and when build and test failures occur. It's always good to pay extra special attention on the mornings after you make a commit or someone makes a commit on your behalf. The normal reaction to &quot;breaking the build&quot; is to log a bug, notify the platform-releng-dev list about it so that others can gauge the quality of the build, and then fix the bug. If your mail client allows it might be a good idea to setup a filter to flag anything with &quot;databinding&quot; in the message from platform-releng-dev. This will help filter out the signal from the noise.<br />
<br />
== Newsgroup==<br />
We try to be prompt and responsive on the [http://www.eclipse.org/newsportal/thread.php?group=eclipse.platform newsgroup] but there's always room for improvement. If you know the answer to a query feel free to respond.<br />
<br />
== Wiki==<br />
The wiki is open and can be edited by all. If you find a typo, a broken link, or anything that you view as a small issue feel free to fix it. If wanting to contribute a significant amount of information or create a new article we request that you [[../FAQ#How_do_I_report_a_bug.3F|log a bug]] so that we're aware of what you're contributing. This is so that we can ensure consistency structurally and in the message conveyed.</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/How_to_ContributeJFace Data Binding/How to Contribute2007-08-25T15:57:30Z<p>Bradleyjames.gmail.com: /* Checking out the Projects */</p>
<hr />
<div>This page is a starting point for where to begin when wanting to contribute to the project. The goal is educate and to be as up front as possible with expectations so that the process can be as efficient as possible.<br />
<br />
== Contributing Code ==<br />
Whether you're wanting to fix a typo in javadoc or to implement the next whiz bang feature of JDB you'll need to know a few things before you contribute code.<br />
<br />
=== Checking out the Plug-ins ===<br />
The project is comprised of the following plug-ins.<br />
* org.eclipse.core.databinding<br />
* org.eclipse.core.databinding.beans<br />
* org.eclipse.jface.databinding<br />
* org.eclipse.jface.databinding.examples<br />
* org.eclipse.jface.tests.databinding<br />
<br />
You can check these out from CVS manually or with a [http://www.eclipse.org/eclipse/platform-ui/psf/ Project Set File]. You can import the file into Eclipse via File-&gt;Import, Team-&gt;Team Project Set. This will check out the necessary projects into your workspace. We provide Project Sets for committers and contributors and for HEAD and maintenance branches.<br />
<br />
=== Unit Testing ===<br />
Testing is imperative to the health of the project. We have a significant amount of tests. The quantity of tests will keep growing as more functionality is added to the library. If you are contributing a fix or writing an enhancement it's a requirement that tests are written. If you don't write them a committer will have to and that could slow down the contribution process. <br />
<br />
There are a couple of things that you should know about our testing process:<br />
* All tests are included in org.eclipse.jface.tests.databinding.<br />
* If looking for tests for a specific class look for a class named {THECLASS}Test.java (e.g. UpdateStrategy.java -&gt; UpdateStrategyTest.java).<br />
* To run all tests open the Run Configuration dialog (Run-&gt;Open Run Dialog...). Under JUnit Plug-in Test will reside a &quot;JFace-Data Binding Test Suite&quot; (this is contributed by org.eclipse.jface.tests.databinding). When invoked this will run all tests. Before you contribute code you should always run the test suite to ensure that your changes didn't break anything, or at least anything that is being tested for.<br />
* If you create a new TestCase make sure to add it to BindingTestSuite. Your TestCase will then be ran as part of the JFace-Data Binding Test Suite.<br />
* If you want to make a good impression write tests. This goes for any project but especially JDB.<br />
<br />
=== The Build ===<br />
The Eclipse build is a bit of a mystery to newcomers. But rest assured that if you break something everyone will know about it and we will laugh at you (not really but we might tease you). If you do one thing it should be to sign up for the [https://dev.eclipse.org/mailman/listinfo/platform-releng-dev platform-releng-dev mailing list]. You'll receive emails when builds complete and when build and test failures occur. It's always good to pay extra special attention on the mornings after you make a commit or someone makes a commit on your behalf. The normal reaction to &quot;breaking the build&quot; is to log a bug, notify the platform-releng-dev list about it so that others can gauge the quality of the build, and then fix the bug. If your mail client allows it might be a good idea to setup a filter to flag anything with &quot;databinding&quot; in the message from platform-releng-dev. This will help filter out the signal from the noise.</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/How_to_ContributeJFace Data Binding/How to Contribute2007-08-24T01:52:40Z<p>Bradleyjames.gmail.com: /* The Build */</p>
<hr />
<div>This page is a starting point for where to begin when wanting to contribute to the project. The goal is educate and to be as up front as possible with expectations so that the process can be as efficient as possible.<br />
<br />
== Contributing Code ==<br />
Whether you're wanting to fix a typo in javadoc or to implement the next whiz bang feature of JDB you'll need to know a few things before you contribute code.<br />
<br />
=== Checking out the Projects ===<br />
The project is comprised of the following plug-ins.<br />
* org.eclipse.core.databinding<br />
* org.eclipse.core.databinding.beans<br />
* org.eclipse.jface.databinding<br />
* org.eclipse.jface.databinding.examples<br />
* org.eclipse.jface.tests.databinding<br />
<br />
You can check these out from CVS manually or with a [http://www.eclipse.org/eclipse/platform-ui/psf/ Project Set File]. You can import the file into Eclipse via File-&gt;Import, Team-&gt;Team Project Set. This will check out the necessary projects into your workspace. We provide Project Sets for committers and contributors and for HEAD and maintenance branches.<br />
<br />
=== Unit Testing ===<br />
Testing is imperative to the health of the project. We have a significant amount of tests. The quantity of tests will keep growing as more functionality is added to the library. If you are contributing a fix or writing an enhancement it's a requirement that tests are written. If you don't write them a committer will have to and that could slow down the contribution process. <br />
<br />
There are a couple of things that you should know about our testing process:<br />
* All tests are included in org.eclipse.jface.tests.databinding.<br />
* If looking for tests for a specific class look for a class named {THECLASS}Test.java (e.g. UpdateStrategy.java -&gt; UpdateStrategyTest.java).<br />
* To run all tests open the Run Configuration dialog (Run-&gt;Open Run Dialog...). Under JUnit Plug-in Test will reside a &quot;JFace-Data Binding Test Suite&quot; (this is contributed by org.eclipse.jface.tests.databinding). When invoked this will run all tests. Before you contribute code you should always run the test suite to ensure that your changes didn't break anything, or at least anything that is being tested for.<br />
* If you create a new TestCase make sure to add it to BindingTestSuite. Your TestCase will then be ran as part of the JFace-Data Binding Test Suite.<br />
* If you want to make a good impression write tests. This goes for any project but especially JDB.<br />
<br />
=== The Build ===<br />
The Eclipse build is a bit of a mystery to newcomers. But rest assured that if you break something everyone will know about it and we will laugh at you (not really but we might tease you). If you do one thing it should be to sign up for the [https://dev.eclipse.org/mailman/listinfo/platform-releng-dev platform-releng-dev mailing list]. You'll receive emails when builds complete and when build and test failures occur. It's always good to pay extra special attention on the mornings after you make a commit or someone makes a commit on your behalf. The normal reaction to &quot;breaking the build&quot; is to log a bug, notify the platform-releng-dev list about it so that others can gauge the quality of the build, and then fix the bug. If your mail client allows it might be a good idea to setup a filter to flag anything with &quot;databinding&quot; in the message from platform-releng-dev. This will help filter out the signal from the noise.</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/How_to_ContributeJFace Data Binding/How to Contribute2007-08-24T01:49:23Z<p>Bradleyjames.gmail.com: Added a summary.</p>
<hr />
<div>This page is a starting point for where to begin when wanting to contribute to the project. The goal is educate and to be as up front as possible with expectations so that the process can be as efficient as possible.<br />
<br />
== Contributing Code ==<br />
Whether you're wanting to fix a typo in javadoc or to implement the next whiz bang feature of JDB you'll need to know a few things before you contribute code.<br />
<br />
=== Checking out the Projects ===<br />
The project is comprised of the following plug-ins.<br />
* org.eclipse.core.databinding<br />
* org.eclipse.core.databinding.beans<br />
* org.eclipse.jface.databinding<br />
* org.eclipse.jface.databinding.examples<br />
* org.eclipse.jface.tests.databinding<br />
<br />
You can check these out from CVS manually or with a [http://www.eclipse.org/eclipse/platform-ui/psf/ Project Set File]. You can import the file into Eclipse via File-&gt;Import, Team-&gt;Team Project Set. This will check out the necessary projects into your workspace. We provide Project Sets for committers and contributors and for HEAD and maintenance branches.<br />
<br />
=== Unit Testing ===<br />
Testing is imperative to the health of the project. We have a significant amount of tests. The quantity of tests will keep growing as more functionality is added to the library. If you are contributing a fix or writing an enhancement it's a requirement that tests are written. If you don't write them a committer will have to and that could slow down the contribution process. <br />
<br />
There are a couple of things that you should know about our testing process:<br />
* All tests are included in org.eclipse.jface.tests.databinding.<br />
* If looking for tests for a specific class look for a class named {THECLASS}Test.java (e.g. UpdateStrategy.java -&gt; UpdateStrategyTest.java).<br />
* To run all tests open the Run Configuration dialog (Run-&gt;Open Run Dialog...). Under JUnit Plug-in Test will reside a &quot;JFace-Data Binding Test Suite&quot; (this is contributed by org.eclipse.jface.tests.databinding). When invoked this will run all tests. Before you contribute code you should always run the test suite to ensure that your changes didn't break anything, or at least anything that is being tested for.<br />
* If you create a new TestCase make sure to add it to BindingTestSuite. Your TestCase will then be ran as part of the JFace-Data Binding Test Suite.<br />
* If you want to make a good impression write tests. This goes for any project but especially JDB.<br />
<br />
=== The Build ===<br />
The Eclipse build is a bit of a mystery to newcomers. But rest assured that if you break something everyone will know about it and we will laugh at you (not really but we might tease you). If you do one thing it should be to sign up for the [https://dev.eclipse.org/mailman/listinfo/platform-releng-dev platform-releng-dev mailing list]. You'll receive emails when builds complete and when build and test failures occur. It's always good to pay extra special attention on the mornings after you make a commit or someone makes a commit on your behalf. The normal reaction to &quot;breaking the build&quot; is to log a bug, notify the platform-releng-dev list about it so that others can gauge the quality of the build, and then fix the bug. If your mail client allows it it might be a good idea to setup a filter to flag anything with &quot;databinding&quot; in the message from platform-releng-dev. This will help filter out the signal from the noise.</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_BindingJFace Data Binding2007-08-24T01:42:44Z<p>Bradleyjames.gmail.com: Added &quot;How to Contribute&quot; link</p>
<hr />
<div>JFace Data Binding is a multi-threaded set of abstractions that allow for automated validation and synchronization of values between objects. This is commonly used for, but not limited to, the binding of user interface components to model attributes. The core concepts behind the project are [[Observables]] and [[Binding | Bindings]]. We provide IObservable implementations for SWT, JFace, and JavaBeans but the core is void of references to these in anticipation of implementations for other projects (e.g. EMF, Swing, etc.).<br />
{{JFace Data Binding}}<br />
== Articles ==<br />
=== Concepts ===<br />
* [[Observables]]<br />
* [[Binding | Bindings]]<br />
* [[Converters]]<br />
* Validators<br />
* [[Realm|Realms]]<br />
* Master Detail<br />
<br />
=== Requirements and Design ===<br />
* [[JFace Data Binding Introduction]]<br />
* [[/Original Design | Original Design Document]]<br />
* [[/Scenarios | Scenarios Document]]<br />
<br />
=== Tutorials &amp; Presentations ===<br />
* [[Media:Databinding.pdf | Dave Orme's EclipseCon 2006 Lightning Talk slides]] ''(The code in this presentation is out of date and should not be used as an example but the concepts are still relevant.)''<br />
* [https://admin.adobe.acrobat.com/_a300965365/p77464314/ JFace Data Binding Webinar]<br />
* [[Media:Databinding.zip | Dave and Boris's EclipseCon 2007 long talk and slides]]<br />
<br />
=== Miscellaneous ===<br />
* [[/FAQ | FAQ]]<br />
* [[/How to Contribute | How to Contribute]]<br />
<br />
== Contact Us ==<br />
The [http://www.eclipse.org/newsportal/thread.php?group=eclipse.platform Platform newsgroup] is the place for discussions and questions relating to JFace Data Binding. When posting please prefix the subject with &quot;[DataBinding]&quot; to allow us to easily find posts related to the project.<br />
<br />
Design discussions and bugs are located on [https://bugs.eclipse.org/bugs/ Eclipse bugzilla] with a the values...<br />
; Classification : Eclipse <br />
; Product : Platform<br />
; Component : UI<br />
<br />
Like posts to the newsgroup when logging bugs please prefix the summary with &quot;[DataBinding]&quot; to allow for easier identification.<br />
<br />
== Getting Involved ==<br />
There are many ways to get involved with JFace Data Binding...<br />
* Answer questions on newsgroup - we try to be prompt and responsive on the [http://www.eclipse.org/newsportal/thread.php?group=eclipse.platform newsgroup] but there's always room for improvement. If you know the answer to a query feel free to answer.<br />
* Write patches for new or existing bugs - When logging a bug if a patch is included it will increase the likelihood and speed at which the fix is made. To make a great impression, attach a test as well.<br />
* Write documentation or tutorials - A project can never have too much documentation. We're in need of updates for the wiki and we're looking for more tutorials.<br />
* Let us know how you feel - Feedback, whether positive or negative, is always appreciated. This can be done via the newsgroup, existing bugs, or plan items in bugzilla.<br />
<br />
== Project Status ==<br />
JFace Data Binding 1.0 was releaseed with Eclipse 3.3, [[Europa Simultaneous Release | Europa]]. We're currently working on the 3.3.1 maintenance release as well as enhancements for 3.4.<br />
<br />
[[Category:Data Binding]]</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/How_to_ContributeJFace Data Binding/How to Contribute2007-08-24T01:42:28Z<p>Bradleyjames.gmail.com: New page: == Contributing Code == Whether you're wanting to fix a typo in javadoc or to implement the next whiz bang feature of JDB you'll need to know a few things before you contribute code. === ...</p>
<hr />
<div>== Contributing Code ==<br />
Whether you're wanting to fix a typo in javadoc or to implement the next whiz bang feature of JDB you'll need to know a few things before you contribute code.<br />
<br />
=== Checking out the Projects ===<br />
The project is comprised of the following plug-ins.<br />
* org.eclipse.core.databinding<br />
* org.eclipse.core.databinding.beans<br />
* org.eclipse.jface.databinding<br />
* org.eclipse.jface.databinding.examples<br />
* org.eclipse.jface.tests.databinding<br />
<br />
You can check these out from CVS manually or with a [http://www.eclipse.org/eclipse/platform-ui/psf/ Project Set File]. You can import the file into Eclipse via File-&gt;Import, Team-&gt;Team Project Set. This will check out the necessary projects into your workspace. We provide sets for committers and contributors and for HEAD and maintenance branches.<br />
<br />
=== Unit Testing ===<br />
Testing is imperative to the health of the project. We have a significant amount of tests. The quantity of tests will keep growing as more functionality is added to the library. If you are contributing a fix or writing an enhancement it's a requirement that tests are written. If you don't write them a committer will have to and that could slow down the contribution process. <br />
<br />
There are a couple of things that you should know about our testing process:<br />
* All tests are included in org.eclipse.jface.tests.databinding.<br />
* If looking for tests for a specific class look for a class named {THECLASS}Test.java (e.g. UpdateStrategy.java -&gt; UpdateStrategyTest.java).<br />
* To run all tests open the Run Configuration dialog (Run-&gt;Open Run Dialog...). Under JUnit Plug-in Test will reside a &quot;JFace-Data Binding Test Suite&quot; (this is contributed by org.eclipse.jface.tests.databinding). When invoked this will run all tests. Before you contribute code you should always run the test suite to ensure that your changes didn't break anything, or at least anything that is being tested for.<br />
* If you create a new TestCase make sure to add it to BindingTestSuite. Your TestCase will then be ran as part of the JFace-Data Binding Test Suite.<br />
* If you want to make a good impression write tests. This goes for any project but especially JDB.<br />
<br />
=== The Build ===<br />
The Eclipse build is a bit of a mystery to newcomers. But rest assured that if you break something everyone will know about it and we will laugh at you (not really but we might tease you). If you do one thing it should be to sign up for the [https://dev.eclipse.org/mailman/listinfo/platform-releng-dev platform-releng-dev mailing list]. You'll receive emails when builds complete and when build and test failures occur. It's always good to pay extra special attention on the mornings after you make a commit or someone makes a commit on your behalf. The normal reaction to &quot;breaking the build&quot; is to log a bug, notify the platform-releng-dev list about it so that others can gauge the quality of the build, and then fix the bug. If your mail client allows it it might be a good idea to setup a filter to flag anything with &quot;databinding&quot; in the message from platform-releng-dev. This will help filter out the signal from the noise.</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/FAQJFace Data Binding/FAQ2007-08-20T13:56:27Z<p>Bradleyjames.gmail.com: Added project set file information.</p>
<hr />
<div>{{JFace Data Binding}}<br />
=== Does Data Binding depend upon Eclipse? ===<br />
The core Data Binding plug-in only depends upon org.eclipse.equinox.common and no other parts of Eclipse. There are parts of Data Binding that depend upon SWT/JFace but these have been broken out into a separate plug-in, org.eclipse.jface.databinding. For a discussion of why the core depends upon equinox common see {{bug comment|153630|9}}.<br />
<br />
=== Does Data Binding depend upon SWT? ===<br />
No. Data Binding is meant to be UI toolkit agnostic and more specifically UI agnostic. There is default support for SWT and JFace but this is in the org.eclipse.jface.databinding project which is separate from the core Data Binding APIs that live in org.eclipse.core.databinding. For background and when the separation occurred in see {{bug|153630}}.<br />
<br />
=== How do I report a bug? ===<br />
On the [https://bugs.eclipse.org/bugs Eclipse bugzilla] log a bug to Eclipse &gt; Platform &gt; UI with &quot;[DataBinding]&quot; in the summary.<br />
<br />
=== When will the public API be ready? ===<br />
The majority of refactorings have occurred. We have few planned before [http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_3.html 3.3M6] (API freeze) but we still reserve the right tweak the API as we see fit until then. The 1.0 version will be a part of Eclipse 3.3. (Technically, it will be version 1.1, because version 1.0 of data binding shipped with Eclipse 3.2.) To view the plan item for this see {{bug|154132}}.<br />
<br />
=== Where can I ask a question? ===<br />
You can ask questions on the [http://www.eclipse.org/newsportal/thread.php?group=eclipse.platform Eclipse Platform newsgroup]. When you post please prefix the title with &quot;[DataBinding]&quot;.<br />
<br />
=== How do I bind to the ValidationError of a Binding or DataBindingContext? ===<br />
See [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.examples.databinding/src/org/eclipse/jface/examples/databinding/snippets/Snippet004DataBindingContextErrorLabel.java?rev=HEAD&amp;content-type=text/vnd.viewcvs-markup snippet 004].<br />
<br />
=== How do I run the tests? ===<br />
In order to run the tests you need to have the following projects in your workspace:<br />
* org.eclipse.core.databinding<br />
* org.eclipse.core.databinding.beans<br />
* org.eclipse.jface.databinding<br />
* org.eclipse.jface.examples.databinding<br />
* org.eclipse.jface.tests.databinding<br />
<br />
Rather than checking these projects out one by one we publish [http://www.eclipse.org/eclipse/platform-ui/psf/ project set files] to do this for you. All you need to do is to download the appropriate file, import it into your workspace (File-&gt;Import-&gt;Team-&gt;Team Project Set), and the projects will be checked out for you.<br />
<br />
View the run configurations in your workspace (Run-&gt;Run...). Run JUnit Plug-in Test-&gt;JFace-Data Binding Test Suite.<br />
<br />
=== Where can I get the plugins? ===<br />
The JFace Data Binding plug-ins can be found in any of the following distributions on the Eclipse [http://download.eclipse.org/eclipse/downloads/ download page]:<br />
* Eclipse SDK<br />
* RCP Runtime/SDK<br />
* Platform Runtime/SDK<br />
<br />
Just select the desired build (e.g. stable, integration, nightly) and download one of the above distributions.<br />
<br />
=== Where can I find examples of how to use data binding? ===<br />
The [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.examples.databinding/ org.eclipse.jface.examples.databinding project] contains [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.examples.databinding/src/org/eclipse/jface/examples/databinding/snippets/ snippets] that demonstrate some of the more common usages of the API.<br />
<br />
=== Can JFace Data Binding run against Eclipse 3.2.x? ===<br />
Yes, but depending upon your needs you might need to take an extra step. The 1.0 version of JDB does not depend upon Eclipse 3.3 APIs. But the org.eclipse.jface.databinding plug-in distributed by Eclipse will only run against Eclipse 3.3. The distributions of org.eclipse.core.databinding and org.eclipse.core.databinding.beans will run just fine against Eclipse 3.2.x. If wanting to run org.eclipse.jface.databinding against Eclipse 3.2.x you'll need to build it from source against your target platform. For more information as to why this is necessary see {{bug|177476}}.<br />
<br />
[[Category:FAQ]]<br />
[[Category:Data Binding]]</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_BindingJFace Data Binding2007-08-20T03:16:57Z<p>Bradleyjames.gmail.com: /* Project Status */</p>
<hr />
<div>JFace Data Binding is a multi-threaded set of abstractions that allow for automated validation and synchronization of values between objects. This is commonly used for, but not limited to, the binding of user interface components to model attributes. The core concepts behind the project are [[Observables]] and [[Binding | Bindings]]. We provide IObservable implementations for SWT, JFace, and JavaBeans but the core is void of references to these in anticipation of implementations for other projects (e.g. EMF, Swing, etc.).<br />
{{JFace Data Binding}}<br />
== Articles ==<br />
=== Concepts ===<br />
* [[Observables]]<br />
* [[Binding | Bindings]]<br />
* [[Converters]]<br />
* Validators<br />
* [[Realm|Realms]]<br />
* Master Detail<br />
<br />
=== Requirements and Design ===<br />
* [[JFace Data Binding Introduction]]<br />
* [[/Original Design | Original Design Document]]<br />
* [[/Scenarios | Scenarios Document]]<br />
<br />
=== Tutorials &amp; Presentations ===<br />
* [[Media:Databinding.pdf | Dave Orme's EclipseCon 2006 Lightning Talk slides]] ''(The code in this presentation is out of date and should not be used as an example but the concepts are still relevant.)''<br />
* [https://admin.adobe.acrobat.com/_a300965365/p77464314/ JFace Data Binding Webinar]<br />
* [[Media:Databinding.zip | Dave and Boris's EclipseCon 2007 long talk and slides]]<br />
<br />
=== Miscellaneous ===<br />
* [[/FAQ | FAQ]]<br />
<br />
== Contact Us ==<br />
The [http://www.eclipse.org/newsportal/thread.php?group=eclipse.platform Platform newsgroup] is the place for discussions and questions relating to JFace Data Binding. When posting please prefix the subject with &quot;[DataBinding]&quot; to allow us to easily find posts related to the project.<br />
<br />
Design discussions and bugs are located on [https://bugs.eclipse.org/bugs/ Eclipse bugzilla] with a the values...<br />
; Classification : Eclipse <br />
; Product : Platform<br />
; Component : UI<br />
<br />
Like posts to the newsgroup when logging bugs please prefix the summary with &quot;[DataBinding]&quot; to allow for easier identification.<br />
<br />
== Getting Involved ==<br />
There are many ways to get involved with JFace Data Binding...<br />
* Answer questions on newsgroup - we try to be prompt and responsive on the [http://www.eclipse.org/newsportal/thread.php?group=eclipse.platform newsgroup] but there's always room for improvement. If you know the answer to a query feel free to answer.<br />
* Write patches for new or existing bugs - When logging a bug if a patch is included it will increase the likelihood and speed at which the fix is made. To make a great impression, attach a test as well.<br />
* Write documentation or tutorials - A project can never have too much documentation. We're in need of updates for the wiki and we're looking for more tutorials.<br />
* Let us know how you feel - Feedback, whether positive or negative, is always appreciated. This can be done via the newsgroup, existing bugs, or plan items in bugzilla.<br />
<br />
== Project Status ==<br />
JFace Data Binding 1.0 was releaseed with Eclipse 3.3, [[Europa Simultaneous Release | Europa]]. We're currently working on the 3.3.1 maintenance release as well as enhancements for 3.4.<br />
<br />
[[Category:Data Binding]]</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/Conformance_TestsJFace Data Binding/Conformance Tests2007-07-23T00:17:37Z<p>Bradleyjames.gmail.com: Added disclaimer about suite() approach.</p>
<hr />
<div>The JFace Data Binding TCK is a suite of tests and other files that allow for asserting the conformance of implementations to the abstractions provided by the library.<br />
<br />
'''The TCK is not yet available but will be soon for early adopters.'''<br />
<br />
== Observables ==<br />
The TCK provides tests for the assertion of conformance to the observable specifications. Tests are currently provided for implementations of:<br />
* IObservable<br />
* IObservableValue<br />
* IObservableCollection<br />
* IObservableList<br />
<br />
Tests are broken up into mutable and immutable test cases (e.g. ObservableValueContractTest and MutableObservableValueContractTest). The reason for this is that not all implementations allow for all a consumer to mutate the observable via its API. The TCK tests assert the following when appropriate:<br />
* Change events and their diffs<br />
* Realm checking<br />
* ObservableTracker.getterCalled(IObservable) invocations<br />
* Value types<br />
<br />
The TCK tests don't assert the observed object state. Because the observed object can be of any type and the value can be in any form this isn't something that we feel we can reliably provide. It would be more straightforward for these to remain in your own tests.<br />
<br />
=== Delegates ===<br />
In order to take advantage of the tests developers will need to create a contract delegate. The delegates allow for implementation specific details to be provided to the TCK. The IObservableContractDelegate is provided below as an example:<br />
<br />
public interface IObservableContractDelegate {<br />
/**<br />
* Notifies the delegate of the start of a test.<br />
*/<br />
public void setUp();<br />
<br />
/**<br />
* Notifies the delegate of the end of a test.<br />
*/<br />
public void tearDown();<br />
<br />
/**<br />
* Invokes an operation to set the stale state of the provided<br />
* &lt;code&gt;observable&lt;/code&gt;.<br />
* <br />
* @param observable<br />
* @param stale<br />
*/<br />
public void setStale(IObservable observable, boolean stale);<br />
<br />
/**<br />
* Creates a new observable.<br />
* <br />
* @param realm realm of the observable<br />
* @return observable<br />
*/<br />
public IObservable createObservable(Realm realm);<br />
<br />
/**<br />
* Invokes a change operation on the observable resulting in a change event<br />
* being fired from the observable.<br />
* <br />
* @param observable<br />
*/<br />
public void change(IObservable observable);<br />
}<br />
<br />
The delegate API follows the standard JUnit conventions of setUp() and tearDown(). The other methods will be invoked when necessary by the tests.<br />
<br />
The delegates provided are:<br />
* IObservableContractDelegate<br />
* IObservableValueContractDelegate<br />
* IObservableCollectionContractDelegate<br />
<br />
Your observable implementation will determine which delegate to constuct.<br />
<br />
=== Integration into Tests ===<br />
Since the tests are JUnit3 tests you can integrate them into your tests in standard ways. The two most common ways are by subclassing or creating a suite.<br />
<br />
==== Subclassing ====<br />
public class ButtonObservableValueTest extends SWTObservableValueContractTest {<br />
public ButtonObservableValueTest() {<br />
super(new Delegate());<br />
}<br />
<br />
/* package */ static class Delegate extends AbstractObservableValueContractDelegate {<br />
private Shell shell;<br />
private Button button;<br />
<br />
public void setUp() {<br />
shell = new Shell();<br />
button = new Button(shell, SWT.CHECK);<br />
}<br />
<br />
public void tearDown() {<br />
shell.dispose();<br />
}<br />
<br />
public IObservableValue createObservableValue(Realm realm) {<br />
return new ButtonObservableValue(realm, button);<br />
}<br />
<br />
public void change(IObservable observable) {<br />
boolean value = button.getSelection();<br />
button.setSelection(!value);<br />
button.notifyListeners(SWT.Selection, null);<br />
}<br />
<br />
public Object createValue(IObservableValue observable) {<br />
return (Boolean.TRUE.equals(observable.getValue()) ? Boolean.FALSE : Boolean.TRUE);<br />
}<br />
<br />
public Object getValueType(IObservableValue observable) {<br />
return Boolean.TYPE;<br />
}<br />
}<br />
}<br />
<br />
When subclassing, because of single inheritance, you will will have to create multiple implementations to test the mutable and immutable use cases (e.g. there would need to be a ButtonMutableObservableValueTest as well to test the mutable cases). The rest of the implementation should be straightforward. The only thing we ask is that you don't depend upon API other than the constructors. Tests are public because JUnit requires them to be, not because we want to commit to them as API. Over time we would like to have the opportunity to rename, add, remove, or optimize the test methods to ensure that we're getting the best coverage as possible.<br />
<br />
==== JUnit suite() ====<br />
public class ButtonObservableValueTest extends TestCase {<br />
public static Test suite() {<br />
Delegate delegate = new Delegate();<br />
<br />
return new SuiteBuilder().addTests(ButtonObservableValueTest.class)<br />
.addObservableContractTest(<br />
SWTObservableValueContractTest.class, delegate)<br />
.addObservableContractTest(<br />
SWTMutableObservableValueContractTest.class, delegate)<br />
.build();<br />
}<br />
<br />
/* package */ static class Delegate extends AbstractObservableValueContractDelegate {<br />
private Shell shell;<br />
private Button button;<br />
<br />
public void setUp() {<br />
shell = new Shell();<br />
button = new Button(shell, SWT.CHECK);<br />
}<br />
<br />
public void tearDown() {<br />
shell.dispose();<br />
}<br />
<br />
public IObservableValue createObservableValue(Realm realm) {<br />
return new ButtonObservableValue(realm, button);<br />
}<br />
<br />
public void change(IObservable observable) {<br />
boolean value = button.getSelection();<br />
button.setSelection(!value);<br />
button.notifyListeners(SWT.Selection, null);<br />
}<br />
<br />
public Object createValue(IObservableValue observable) {<br />
return (Boolean.TRUE.equals(observable.getValue()) ? Boolean.FALSE : Boolean.TRUE);<br />
}<br />
<br />
public Object getValueType(IObservableValue observable) {<br />
return Boolean.TYPE;<br />
}<br />
}<br />
} <br />
<br />
By creating a suite() method you can create a custom suite of tests to run. This will allow you to run multiple TestCases from a single test eliminating the need to create multiple implementations for the mutable and immutable cases. The &lt;code&gt;SuiteBuilder&lt;/code&gt; implementation allows for a straightforward way to build these suites. The downside to building tests in this fashion is that when ran they don't contain the context of a parent class. In the JUnit view in Eclipse they are children of a junit.framework.TestSuite rather than a named test. Options are being investigated to remedy this problem.</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/Conformance_TestsJFace Data Binding/Conformance Tests2007-07-23T00:14:40Z<p>Bradleyjames.gmail.com: Added what the TCK tests in observables.</p>
<hr />
<div>The JFace Data Binding TCK is a suite of tests and other files that allow for asserting the conformance of implementations to the abstractions provided by the library.<br />
<br />
'''The TCK is not yet available but will be soon for early adopters.'''<br />
<br />
== Observables ==<br />
The TCK provides tests for the assertion of conformance to the observable specifications. Tests are currently provided for implementations of:<br />
* IObservable<br />
* IObservableValue<br />
* IObservableCollection<br />
* IObservableList<br />
<br />
Tests are broken up into mutable and immutable test cases (e.g. ObservableValueContractTest and MutableObservableValueContractTest). The reason for this is that not all implementations allow for all a consumer to mutate the observable via its API. The TCK tests assert the following when appropriate:<br />
* Change events and their diffs<br />
* Realm checking<br />
* ObservableTracker.getterCalled(IObservable) invocations<br />
* Value types<br />
<br />
The TCK tests don't assert the observed object state. Because the observed object can be of any type and the value can be in any form this isn't something that we feel we can reliably provide. It would be more straightforward for these to remain in your own tests.<br />
<br />
=== Delegates ===<br />
In order to take advantage of the tests developers will need to create a contract delegate. The delegates allow for implementation specific details to be provided to the TCK. The IObservableContractDelegate is provided below as an example:<br />
<br />
public interface IObservableContractDelegate {<br />
/**<br />
* Notifies the delegate of the start of a test.<br />
*/<br />
public void setUp();<br />
<br />
/**<br />
* Notifies the delegate of the end of a test.<br />
*/<br />
public void tearDown();<br />
<br />
/**<br />
* Invokes an operation to set the stale state of the provided<br />
* &lt;code&gt;observable&lt;/code&gt;.<br />
* <br />
* @param observable<br />
* @param stale<br />
*/<br />
public void setStale(IObservable observable, boolean stale);<br />
<br />
/**<br />
* Creates a new observable.<br />
* <br />
* @param realm realm of the observable<br />
* @return observable<br />
*/<br />
public IObservable createObservable(Realm realm);<br />
<br />
/**<br />
* Invokes a change operation on the observable resulting in a change event<br />
* being fired from the observable.<br />
* <br />
* @param observable<br />
*/<br />
public void change(IObservable observable);<br />
}<br />
<br />
The delegate API follows the standard JUnit conventions of setUp() and tearDown(). The other methods will be invoked when necessary by the tests.<br />
<br />
The delegates provided are:<br />
* IObservableContractDelegate<br />
* IObservableValueContractDelegate<br />
* IObservableCollectionContractDelegate<br />
<br />
Your observable implementation will determine which delegate to constuct.<br />
<br />
=== Integration into Tests ===<br />
Since the tests are JUnit3 tests you can integrate them into your tests in standard ways. The two most common ways are by subclassing or creating a suite.<br />
<br />
==== Subclassing ====<br />
public class ButtonObservableValueTest extends SWTObservableValueContractTest {<br />
public ButtonObservableValueTest() {<br />
super(new Delegate());<br />
}<br />
<br />
/* package */ static class Delegate extends AbstractObservableValueContractDelegate {<br />
private Shell shell;<br />
private Button button;<br />
<br />
public void setUp() {<br />
shell = new Shell();<br />
button = new Button(shell, SWT.CHECK);<br />
}<br />
<br />
public void tearDown() {<br />
shell.dispose();<br />
}<br />
<br />
public IObservableValue createObservableValue(Realm realm) {<br />
return new ButtonObservableValue(realm, button);<br />
}<br />
<br />
public void change(IObservable observable) {<br />
boolean value = button.getSelection();<br />
button.setSelection(!value);<br />
button.notifyListeners(SWT.Selection, null);<br />
}<br />
<br />
public Object createValue(IObservableValue observable) {<br />
return (Boolean.TRUE.equals(observable.getValue()) ? Boolean.FALSE : Boolean.TRUE);<br />
}<br />
<br />
public Object getValueType(IObservableValue observable) {<br />
return Boolean.TYPE;<br />
}<br />
}<br />
}<br />
<br />
When subclassing, because of single inheritance, you will will have to create multiple implementations to test the mutable and immutable use cases (e.g. there would need to be a ButtonMutableObservableValueTest as well to test the mutable cases). The rest of the implementation should be straightforward. The only thing we ask is that you don't depend upon API other than the constructors. Tests are public because JUnit requires them to be, not because we want to commit to them as API. Over time we would like to have the opportunity to rename, add, remove, or optimize the test methods to ensure that we're getting the best coverage as possible.<br />
<br />
==== JUnit suite() ====<br />
public class ButtonObservableValueTest extends TestCase {<br />
public static Test suite() {<br />
Delegate delegate = new Delegate();<br />
<br />
return new SuiteBuilder().addTests(ButtonObservableValueTest.class)<br />
.addObservableContractTest(<br />
SWTObservableValueContractTest.class, delegate)<br />
.addObservableContractTest(<br />
SWTMutableObservableValueContractTest.class, delegate)<br />
.build();<br />
}<br />
<br />
/* package */ static class Delegate extends AbstractObservableValueContractDelegate {<br />
private Shell shell;<br />
private Button button;<br />
<br />
public void setUp() {<br />
shell = new Shell();<br />
button = new Button(shell, SWT.CHECK);<br />
}<br />
<br />
public void tearDown() {<br />
shell.dispose();<br />
}<br />
<br />
public IObservableValue createObservableValue(Realm realm) {<br />
return new ButtonObservableValue(realm, button);<br />
}<br />
<br />
public void change(IObservable observable) {<br />
boolean value = button.getSelection();<br />
button.setSelection(!value);<br />
button.notifyListeners(SWT.Selection, null);<br />
}<br />
<br />
public Object createValue(IObservableValue observable) {<br />
return (Boolean.TRUE.equals(observable.getValue()) ? Boolean.FALSE : Boolean.TRUE);<br />
}<br />
<br />
public Object getValueType(IObservableValue observable) {<br />
return Boolean.TYPE;<br />
}<br />
}<br />
} <br />
<br />
By creating a suite() method you can create a custom suite of tests to run. This will allow you to run multiple TestCases from a single test eliminating the need to create multiple implementations for the mutable and immutable cases. The &lt;code&gt;SuiteBuilder&lt;/code&gt; implementation allows for a straightforward way to build these suites.</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/Conformance_TestsJFace Data Binding/Conformance Tests2007-07-22T18:37:30Z<p>Bradleyjames.gmail.com: Added disclaimer saying that the TCK is not available.</p>
<hr />
<div>The JFace Data Binding TCK is a suite of tests and other files that allow for asserting the conformance of implementations to the abstractions provided by the library.<br />
<br />
'''The TCK is not yet available but will be soon for early adopters.'''<br />
<br />
== Observables ==<br />
The TCK provides tests for the assertion of conformance to the observable specifications. Tests are currently provided for implementations of:<br />
* IObservable<br />
* IObservableValue<br />
* IObservableCollection<br />
* IObservableList<br />
<br />
Tests are broken up into mutable and immutable test cases (e.g. ObservableValueContractTest and MutableObservableValueContractTest). The reason for this is that not all implementations allow for all a consumer to mutate the observable via its API.<br />
<br />
=== Delegates ===<br />
In order to take advantage of the tests developers will need to create a contract delegate. The delegates allow for implementation specific details to be provided to the TCK. The IObservableContractDelegate is provided below as an example:<br />
<br />
public interface IObservableContractDelegate {<br />
/**<br />
* Notifies the delegate of the start of a test.<br />
*/<br />
public void setUp();<br />
<br />
/**<br />
* Notifies the delegate of the end of a test.<br />
*/<br />
public void tearDown();<br />
<br />
/**<br />
* Invokes an operation to set the stale state of the provided<br />
* &lt;code&gt;observable&lt;/code&gt;.<br />
* <br />
* @param observable<br />
* @param stale<br />
*/<br />
public void setStale(IObservable observable, boolean stale);<br />
<br />
/**<br />
* Creates a new observable.<br />
* <br />
* @param realm realm of the observable<br />
* @return observable<br />
*/<br />
public IObservable createObservable(Realm realm);<br />
<br />
/**<br />
* Invokes a change operation on the observable resulting in a change event<br />
* being fired from the observable.<br />
* <br />
* @param observable<br />
*/<br />
public void change(IObservable observable);<br />
}<br />
<br />
The delegate API follows the standard JUnit conventions of setUp() and tearDown(). The other methods will be invoked when necessary by the tests.<br />
<br />
The delegates provided are:<br />
* IObservableContractDelegate<br />
* IObservableValueContractDelegate<br />
* IObservableCollectionContractDelegate<br />
<br />
Your observable implementation will determine which delegate to constuct.<br />
<br />
=== Integration into Tests ===<br />
Since the tests are JUnit3 tests you can integrate them into your tests in standard ways. The two most common ways are by subclassing or creating a suite.<br />
<br />
==== Subclassing ====<br />
public class ButtonObservableValueTest extends SWTObservableValueContractTest {<br />
public ButtonObservableValueTest() {<br />
super(new Delegate());<br />
}<br />
<br />
/* package */ static class Delegate extends AbstractObservableValueContractDelegate {<br />
private Shell shell;<br />
private Button button;<br />
<br />
public void setUp() {<br />
shell = new Shell();<br />
button = new Button(shell, SWT.CHECK);<br />
}<br />
<br />
public void tearDown() {<br />
shell.dispose();<br />
}<br />
<br />
public IObservableValue createObservableValue(Realm realm) {<br />
return new ButtonObservableValue(realm, button);<br />
}<br />
<br />
public void change(IObservable observable) {<br />
boolean value = button.getSelection();<br />
button.setSelection(!value);<br />
button.notifyListeners(SWT.Selection, null);<br />
}<br />
<br />
public Object createValue(IObservableValue observable) {<br />
return (Boolean.TRUE.equals(observable.getValue()) ? Boolean.FALSE : Boolean.TRUE);<br />
}<br />
<br />
public Object getValueType(IObservableValue observable) {<br />
return Boolean.TYPE;<br />
}<br />
}<br />
}<br />
<br />
When subclassing, because of single inheritance, you will will have to create multiple implementations to test the mutable and immutable use cases (e.g. there would need to be a ButtonMutableObservableValueTest as well to test the mutable cases). The rest of the implementation should be straightforward. The only thing we ask is that you don't depend upon API other than the constructors. Tests are public because JUnit requires them to be, not because we want to commit to them as API. Over time we would like to have the opportunity to rename, add, remove, or optimize the test methods to ensure that we're getting the best coverage as possible.<br />
<br />
==== JUnit suite() ====<br />
public class ButtonObservableValueTest extends TestCase {<br />
public static Test suite() {<br />
Delegate delegate = new Delegate();<br />
<br />
return new SuiteBuilder().addTests(ButtonObservableValueTest.class)<br />
.addObservableContractTest(<br />
SWTObservableValueContractTest.class, delegate)<br />
.addObservableContractTest(<br />
SWTMutableObservableValueContractTest.class, delegate)<br />
.build();<br />
}<br />
<br />
/* package */ static class Delegate extends AbstractObservableValueContractDelegate {<br />
private Shell shell;<br />
private Button button;<br />
<br />
public void setUp() {<br />
shell = new Shell();<br />
button = new Button(shell, SWT.CHECK);<br />
}<br />
<br />
public void tearDown() {<br />
shell.dispose();<br />
}<br />
<br />
public IObservableValue createObservableValue(Realm realm) {<br />
return new ButtonObservableValue(realm, button);<br />
}<br />
<br />
public void change(IObservable observable) {<br />
boolean value = button.getSelection();<br />
button.setSelection(!value);<br />
button.notifyListeners(SWT.Selection, null);<br />
}<br />
<br />
public Object createValue(IObservableValue observable) {<br />
return (Boolean.TRUE.equals(observable.getValue()) ? Boolean.FALSE : Boolean.TRUE);<br />
}<br />
<br />
public Object getValueType(IObservableValue observable) {<br />
return Boolean.TYPE;<br />
}<br />
}<br />
} <br />
<br />
By creating a suite() method you can create a custom suite of tests to run. This will allow you to run multiple TestCases from a single test eliminating the need to create multiple implementations for the mutable and immutable cases. The &lt;code&gt;SuiteBuilder&lt;/code&gt; implementation allows for a straightforward way to build these suites.</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/Conformance_TestsJFace Data Binding/Conformance Tests2007-07-22T16:16:23Z<p>Bradleyjames.gmail.com: Created JFace Data Binding TCK page</p>
<hr />
<div>The JFace Data Binding TCK is a suite of tests and other files that allow for asserting the conformance of implementations to the abstractions provided by the library.<br />
<br />
== Observables ==<br />
The TCK provides tests for the assertion of conformance to the observable specifications. Tests are currently provided for implementations of:<br />
* IObservable<br />
* IObservableValue<br />
* IObservableCollection<br />
* IObservableList<br />
<br />
Tests are broken up into mutable and immutable test cases (e.g. ObservableValueContractTest and MutableObservableValueContractTest). The reason for this is that not all implementations allow for all a consumer to mutate the observable via its API.<br />
<br />
=== Delegates ===<br />
In order to take advantage of the tests developers will need to create a contract delegate. The delegates allow for implementation specific details to be provided to the TCK. The IObservableContractDelegate is provided below as an example:<br />
<br />
public interface IObservableContractDelegate {<br />
/**<br />
* Notifies the delegate of the start of a test.<br />
*/<br />
public void setUp();<br />
<br />
/**<br />
* Notifies the delegate of the end of a test.<br />
*/<br />
public void tearDown();<br />
<br />
/**<br />
* Invokes an operation to set the stale state of the provided<br />
* &lt;code&gt;observable&lt;/code&gt;.<br />
* <br />
* @param observable<br />
* @param stale<br />
*/<br />
public void setStale(IObservable observable, boolean stale);<br />
<br />
/**<br />
* Creates a new observable.<br />
* <br />
* @param realm realm of the observable<br />
* @return observable<br />
*/<br />
public IObservable createObservable(Realm realm);<br />
<br />
/**<br />
* Invokes a change operation on the observable resulting in a change event<br />
* being fired from the observable.<br />
* <br />
* @param observable<br />
*/<br />
public void change(IObservable observable);<br />
}<br />
<br />
The delegate API follows the standard JUnit conventions of setUp() and tearDown(). The other methods will be invoked when necessary by the tests.<br />
<br />
The delegates provided are:<br />
* IObservableContractDelegate<br />
* IObservableValueContractDelegate<br />
* IObservableCollectionContractDelegate<br />
<br />
Your observable implementation will determine which delegate to constuct.<br />
<br />
=== Integration into Tests ===<br />
Since the tests are JUnit3 tests you can integrate them into your tests in standard ways. The two most common ways are by subclassing or creating a suite.<br />
<br />
==== Subclassing ====<br />
public class ButtonObservableValueTest extends SWTObservableValueContractTest {<br />
public ButtonObservableValueTest() {<br />
super(new Delegate());<br />
}<br />
<br />
/* package */ static class Delegate extends AbstractObservableValueContractDelegate {<br />
private Shell shell;<br />
private Button button;<br />
<br />
public void setUp() {<br />
shell = new Shell();<br />
button = new Button(shell, SWT.CHECK);<br />
}<br />
<br />
public void tearDown() {<br />
shell.dispose();<br />
}<br />
<br />
public IObservableValue createObservableValue(Realm realm) {<br />
return new ButtonObservableValue(realm, button);<br />
}<br />
<br />
public void change(IObservable observable) {<br />
boolean value = button.getSelection();<br />
button.setSelection(!value);<br />
button.notifyListeners(SWT.Selection, null);<br />
}<br />
<br />
public Object createValue(IObservableValue observable) {<br />
return (Boolean.TRUE.equals(observable.getValue()) ? Boolean.FALSE : Boolean.TRUE);<br />
}<br />
<br />
public Object getValueType(IObservableValue observable) {<br />
return Boolean.TYPE;<br />
}<br />
}<br />
}<br />
<br />
When subclassing, because of single inheritance, you will will have to create multiple implementations to test the mutable and immutable use cases (e.g. there would need to be a ButtonMutableObservableValueTest as well to test the mutable cases). The rest of the implementation should be straightforward. The only thing we ask is that you don't depend upon API other than the constructors. Tests are public because JUnit requires them to be, not because we want to commit to them as API. Over time we would like to have the opportunity to rename, add, remove, or optimize the test methods to ensure that we're getting the best coverage as possible.<br />
<br />
==== JUnit suite() ====<br />
public class ButtonObservableValueTest extends TestCase {<br />
public static Test suite() {<br />
Delegate delegate = new Delegate();<br />
<br />
return new SuiteBuilder().addTests(ButtonObservableValueTest.class)<br />
.addObservableContractTest(<br />
SWTObservableValueContractTest.class, delegate)<br />
.addObservableContractTest(<br />
SWTMutableObservableValueContractTest.class, delegate)<br />
.build();<br />
}<br />
<br />
/* package */ static class Delegate extends AbstractObservableValueContractDelegate {<br />
private Shell shell;<br />
private Button button;<br />
<br />
public void setUp() {<br />
shell = new Shell();<br />
button = new Button(shell, SWT.CHECK);<br />
}<br />
<br />
public void tearDown() {<br />
shell.dispose();<br />
}<br />
<br />
public IObservableValue createObservableValue(Realm realm) {<br />
return new ButtonObservableValue(realm, button);<br />
}<br />
<br />
public void change(IObservable observable) {<br />
boolean value = button.getSelection();<br />
button.setSelection(!value);<br />
button.notifyListeners(SWT.Selection, null);<br />
}<br />
<br />
public Object createValue(IObservableValue observable) {<br />
return (Boolean.TRUE.equals(observable.getValue()) ? Boolean.FALSE : Boolean.TRUE);<br />
}<br />
<br />
public Object getValueType(IObservableValue observable) {<br />
return Boolean.TYPE;<br />
}<br />
}<br />
} <br />
<br />
By creating a suite() method you can create a custom suite of tests to run. This will allow you to run multiple TestCases from a single test eliminating the need to create multiple implementations for the mutable and immutable cases. The &lt;code&gt;SuiteBuilder&lt;/code&gt; implementation allows for a straightforward way to build these suites.</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/Eclipse/CommittersEclipse/Committers2007-05-28T22:27:55Z<p>Bradleyjames.gmail.com: Added Colorado Springs</p>
<hr />
<div>&lt;h5&gt;Geographical Locations of Eclipse Project Committers&lt;/h5&gt;<br />
<br />
&lt;h4&gt;Canada&lt;/h4&gt;<br />
Lakeville, NS&lt;br&gt;<br />
Ottawa, ON&lt;br&gt;<br />
Toronto, ON&lt;br&gt;<br />
Winnipeg, MB&lt;br&gt;<br />
Victoria, BC&lt;br&gt;<br />
<br />
&lt;h4&gt;France&lt;/h4&gt;<br />
Saint Nazaire<br />
<br />
&lt;h4&gt;India&lt;/h4&gt;<br />
Bangalore&lt;br&gt;<br />
<br />
&lt;h4&gt;Russia&lt;/h4&gt;<br />
Nizhny Novgorod&lt;br&gt;<br />
<br />
&lt;h4&gt;Switzerland&lt;/h4&gt;<br />
Zurich<br />
<br />
&lt;h4&gt;USA&lt;/h4&gt;<br />
Boston MA, USA&lt;br&gt;<br />
Colorado Springs, CO, USA&lt;br&gt;<br />
Durham, NC, USA&lt;br&gt; <br />
Austin, TX, USA&lt;br&gt; <br />
Beaverton, OR, USA&lt;br&gt; <br />
Seattle, WA, USA&lt;br&gt;<br />
Sunnyvale, CA&lt;br&gt;</div>Bradleyjames.gmail.comhttp://wiki.eclipse.org/JFace_Data_Binding/SnippetsJFace Data Binding/Snippets2007-04-11T01:25:57Z<p>Bradleyjames.gmail.com: Added a link to the TableViewer inline editing snippet</p>
<hr />
<div>Snippets that display common use cases and how they are satisfied with the JFace Data Binding API.<br />
{{JFace Data Binding}}<br />
<br />
=== Basic ===<br />
* [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.examples.databinding/src/org/eclipse/jface/examples/databinding/snippets/Snippet000HelloWorld.java?view=markup Hello World] - the most basic of bindings<br />
<br />
=== ComputedValue ===<br />
* [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.examples.databinding/src/org/eclipse/jface/examples/databinding/snippets/Snippet006Spreadsheet.java?view=markup Spreadsheet] - fills a Table updating cells upon change<br />
* [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.examples.databinding/src/org/eclipse/jface/examples/databinding/snippets/Snippet008ComputedValue.java?view=markup Name Formatter] - observable value that updates when the first or last name changes<br />
<br />
=== Bindings ===<br />
* [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.examples.databinding/src/org/eclipse/jface/examples/databinding/snippets/Snippet004DataBindingContextErrorLabel.java?view=markup Bind validation status to a Label]<br />
* [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.examples.databinding/src/org/eclipse/jface/examples/databinding/snippets/Snippet011ValidateMultipleBindingsSnippet.java?view=markup Validate observables across Bindings]<br />
<br />
=== Master Detail ===<br />
* [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.examples.databinding/src/org/eclipse/jface/examples/databinding/snippets/Snippet010MasterDetail.java?view=markup Master detail] - display the detail of the selection of a ListViewer in a Text widget<br />
* [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.examples.databinding/src/org/eclipse/jface/examples/databinding/snippets/Snippet001NestedSelectionWithCombo.java?view=markup Nested Selection With ComboViewer]<br />
<br />
=== SWT ===<br />
* [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.examples.databinding/src/org/eclipse/jface/examples/databinding/snippets/Snippet005MenuUpdater.java?view=markup MenuUpdater]<br />
* [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.examples.databinding/src/org/eclipse/jface/examples/databinding/snippets/Snippet012CompositeUpdater.java?view=markup CompositeUpdater]<br />
<br />
=== Viewers ===<br />
* [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.examples.databinding/src/org/eclipse/jface/examples/databinding/snippets/Snippet009TableViewer.java?view=markup Model to TableViewer binding] - basic binding to a TableViewer<br />
* [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.examples.databinding/src/org/eclipse/jface/examples/databinding/snippets/Snippet007ColorLabelProvider.java?view=markup TableViewer binding with colors] - label provider that provides Colors and auto updates the viewer<br />
* [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.examples.databinding/src/org/eclipse/jface/examples/databinding/snippets/Snippet013TableViewerEditing.java?view=markup TableViewer inline editing] - TableViewer editing with the Eclipse 3.3 JFace viewer APIs. ''(requires Eclipse 3.3)''<br />
[[Category:Data Binding]]</div>Bradleyjames.gmail.com