Bugzilla – Full Text Bug Listing
| Summary: | [DataBinding] Data binding framework for SWT and RCP needed | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Dave Orme <djo> | ||||||||
| Component: | UI | Assignee: | Boris Bokowski <bokowski> | ||||||||
| Status: | RESOLVED DUPLICATE | QA Contact: | |||||||||
| Severity: | enhancement | ||||||||||
| Priority: | P3 | CC: | alexberns, bill, bokowski, bondtnt, bradleyjames, burs, c.hauser, chris_42, chs, codex69, dev, douglas.pollock, eclipse, ed.burnette, elias, fg, gmendel, gunnar, hugo.a.garcia, Joel.Kamentz, john.ruud, karsten, Konstantin.Scheglov, markus.kell.r, michaelvanmeekeren, mike.haller, mlists, mm, morten-eclipse, n.a.edgar, nicolas.gouy, pascal, psodre, schtoo, sdavids, sgunturi, susan, Tod_Creasey, unknown, vimalvachhani, walkerp, Winchest, wmitsuda, yharms | ||||||||
| Version: | 3.1 | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Dave Orme
Adding [Viewers] tag as we want the data binding support to align well with JFace viewers. Just capturing an important part of our technical discussion here for posterity. ;)
Nick Edgar wrote:
>1) It certainly looks compatible. Although it currently depends on
>org.eclipse.ui, the only dependency on layers higher than SWT is the one
>on ICellEditorValidator. You might want to change it to depend only on
>org.eclipse.jface and org.eclipse.swt, and limit yourself to the utility
>classes in the runtime (see bug 49497 and the runtime-util folder in
>org.eclipse.jface). This would allow Sweet to be used in standalone
>SWT+JFace scenarios. If ICellEditorValidator ends up being the only link
>to JFace, then we could perhaps do that via an adapter and have Sweet
>just depend on SWT.
That's one way to handle that. I agree that the current refactoring
isn't ideal and that this is one way to handle it. But if I do it this
way, I'll just wind up duplicating ICellEditorValidator somewhere under
a different name. Maybe we could come up with a more unified approach?
On the other hand, I hope to extend SWTObjectViewer.bind() to be able to
bind JFace viewers to properties of (collection) objects. This will use
generic strategy pattern objects to automatically provide content
providers, cell editors, etc... So if you're editing any collection
object containing objects with an IObjectViewer implementation, you'll
be able to automatically edit using any JFace viewer with 1 line of
code. :-)
Dave, looked over the refactoring work on the binders in the sweet pkg. They look like a great seed. Though, I think that we need to provide simple, efficient and jFace based code as much as possible. It will be better to provide jFace bindings, rather than a generic binding framework. The current code in CVS makes it possible to bind to any type of visual (Swing, SWT or what ever), using the DuckType and java.lang.reflect. Proxy s. This is cool, but it makes the code more complex and less efficient as if it would just extended the jFace class base, and assume SWT widgets (not to mention that it will be less confusing). IMO we should try to provide jFace binders that extend today’s jFace components. i.e., make an IObjectViewer a jFace viewer (attached somewhere on the current jFace Viewer hierarchy) using some type of IContentProvider and IBaseLabelProvider as the basis for the IEditedObject – there is a stretch moving it to work that way, but it will provide a straightforward progression of what we have today, and simpler to adapt to. (In reply to comment #3) > Dave, looked over the refactoring work on the binders in the sweet pkg. They > look like a great seed. Though, I think that we need to provide simple, > efficient and jFace based code as much as possible. It will be better to > provide jFace bindings, rather than a generic binding framework. You're right that this would be simpler. However, I have business requirements for *today's* db4o applications that go beyond what is supplied by the JFace Viewer framework: - Keystroke-by-keystroke validation for plain Text fields. - Automatic selection of cell validators based on data type. - Validator definition using either plain Java code or using regular expressions (I use both). - Ability to override the built-in default validation with my own. - Ability to support any SWT control or JFace viewer with one code base (my code is a mix of SWT and JFace, as is Eclipse's code base, for exactly the same reasons). This is what I have to be able to deliver today for db4objects. Other folks have described even more aggressive requirements: - Ability to create a new modeless table control (one that is always in edit mode) or to make the current JFace table viewer behave modelessly. - Ability to have the table control do keystroke-level validation like regular text fields, override validation logic, etc. And I have a new project now that also has some of these requirements. JFace by itself just wasn't designed to handle all this. It's a great way to generically attach an arbitrary model to a Tree, Table, or TableTree (or the new 3.1 SWT replacement for TableTree), and do some basic validation that you would need for an IDE. But business applications have more aggressive requirements than this in order to have a high quality user interface. I'm happy to consider other code bases as seed contributions than the one I contributed, but I *must* be able to replace the current Sweet code base with the same or better functionality for my existing customers. Otherwise, that's just a non-starter for me. > The current code in CVS makes it possible to bind to any type of visual (Swing, > SWT or what ever), using the DuckType and java.lang.reflect. Proxy s. This is > cool, but it makes the code more complex and less efficient as if it would just > extended the jFace class base, and assume SWT widgets (not to mention that it > will be less confusing). Actually, the primary intent is to provide a single unified archiecture that can bind data to either JFace or SWT controls. As a side-effect, we get the ability to support Swing in the future if we want to or if somebody wants to contribute that code. > IMO we should try to provide jFace binders that extend > today’s jFace components. i.e., make an IObjectViewer a jFace viewer (attached > somewhere on the current jFace Viewer hierarchy) using some type of > IContentProvider and IBaseLabelProvider as the basis for the IEditedObject – > there is a stretch moving it to work that way, but it will provide a > straightforward progression of what we have today, and simpler to adapt to. I suppose it would be easier if we could just build on top of JFace and ignore that SWT exists. But Eclipse itself is constructed of a mix of JFace and pure SWT controls because there aren't JFace wrappers for every SWT control. Nor do I perceive the Platform/UI team wanting to create JFace wrappers for every SWT control. Nor do I think we want to require everyone in the community to create a JFace wrapper for their new SWT custom controls in order to participate in the data binding framework. I think we need a single data binding API that works with both SWT and JFace. For example, suppose someone in the Eclipse community creates a new SuperText SWT control by extending Composite and embedding a Text object. They want to be API-compatible with Text, so they add API to their Composite that implements the API on Text, plus they add their own new cool functionality. Using the DuckType approach that Sweet uses today, Sweet will automatically support that new control out of the box, without writing a single new line of code. This is because Duck Typing just works based on what methods are present on the object, and our developer (to be as API-compatible with SWT's Text object as possible) has all the same methods on SuperText as Text. But if we take the approach of creating wrapper objects for every SWT control, then we can't automatically work with new SWT controls as the community creates them. Consequently, I really think that any data binding solution for Eclipse as a whole should be agnostic to SWT versus JFace. It should work with either and/or both. There are things you can't do with JFace that you can do with SWT because JFace doesn't provide wrappers for every SWT control. So I think we should support that. Similarly, JFace is the preferred way to map a model to one of the more complicated SWT controls. So I think we should support that too. The cherry on top is that being this generic enables us to support Swing, which politically is a great argument. Sun has been exclusive (excluding Eclipse) in the way it has approached the Java community. Eclipse has been inclusive in its approach to supporting the Java community. This is one reason that Eclipse is perceived to be a safe choice by many. Choosing Sweet's approach lets us continue that tradition of being inclusive, thus continuing to be the safe choice for folks who still have to work with Swing, but also want to work with SWT and JFace. I agree that the data binding framework should target both SWT and JFace. One of the design points of JFace is that it doesn't require wrappering SWT controls (the first version of it did). JFace does not take over SWT responsibilities like control creation and layout, although the viewers do have convenience constructors for creation. When using a JFace viewer, you still have direct access to the underlying control, but since viewers are "model-based adapters to SWT controls", you're expected not to inspect the SWT items directly or hook item-related listeners at SWT level, but rather use the JFace model-based selection methods and listeners. Also note that JFace viewers have no support for typical form controls like Label and Text. There is the FieldEditor framework in JFace, which is kind of data-binding like, but it has several major problems: - limited to working within preference pages (and really only FieldEditorPreferencePages without having to jump through hoops) - assumes the model is a preference store - has bogus layout assumptions I suggest we ignore FieldEditors completely for the data binding support, but that we do consider preference pages as one common scenario for the data binding support. Also note that we are looking at pushing the forms framework (org.eclipse.ui.forms) down into SWT and JFace (excluding the FormEditor support). The idea is that SWT will take over ownership of the extra controls there (and make them native where possible), and there will be factory and layout helpers at JFace level. We should ensure that we align this effort with the data binding effort, e.g. so that we don't have duplicate factory mechanisms. I'm also OK with the Duck Type approach, but bear in mind that we want JFace (and lower layers) to compile and run against the JCL/Foundation profile, for use in embedded devices and to be able to run against lighter-weight JREs in desktop scenarios. I don't believe Foundation has support for dynamic proxies, so we'll need to be able to replace that part of Duck Typing with static proxies for the specific Duck Types defined in the framework. For performance concerns, we should get a quantitative handle on how significant the costs of Duck Typing are, e.g. for tables with 1000s of elements. For typical forms, I'm not concerned at all. The costs of reflection are likely to be much less than the cost of accessing the data source if it's anything more interesting than a POJO. > I think we need a single data binding API that works with both SWT and JFace.
Agreed. I also agree that it would be good to support arbitrary SWT custom
controls if possible.
I am not so sure if being agnostic about the underlying technology is a good
idea though, at least not in the sense of being able to substitute e.g. Swing
for SWT/JFace without changing the code that uses the data binding framework.
Consider the description of JFace (copied from the online documentation):
"JFace is designed to provide common application UI function on top of the SWT
library. JFace does not try to "hide" SWT or replace its function. It provides
classes and interfaces that handle many of the common tasks associated with
programming a dynamic UI using SWT."
I would like the data binding framework to be built in the same spirit: Make
it easy to write simple table/tree/forms-based business applications, but
don't make it impossible to do more advanced things by hiding the underlying
frameworks.
As a concrete example, I would like the data binding framework to provide
default controls with a default layout when creating a simple form for
entering data. However, it should be possible for the programmer to have
complete control over the layout and the controls, while still using
the "binding" part of the framework.
(In reply to comment #7) > I am not so sure if being agnostic about the underlying technology is a good > idea though, at least not in the sense of being able to substitute e.g. Swing > for SWT/JFace without changing the code that uses the data binding framework. > > Consider the description of JFace (copied from the online documentation): > "JFace is designed to provide common application UI function on top of the SWT > library. JFace does not try to "hide" SWT or replace its function. It provides > classes and interfaces that handle many of the common tasks associated with > programming a dynamic UI using SWT." I think we're saying the same thing here. If JFace were toolkit-agnostic, the code that initializes the UI control would be different for each UI toolkit, but the content providers, label providers, etc., would be identical. What I am proposing is exactly this--that you can set up your UI controls using your preferred toolkit (using that toolkit's native code), but the code that is a client to the binding framework would be identical in any case. And that I think this should work for SWT Text and Label (for which there are no JFace viewers) as well as for any JFace viewer, using the same API. > I would like the data binding framework to be built in the same spirit: Make > it easy to write simple table/tree/forms-based business applications, but > don't make it impossible to do more advanced things by hiding the underlying > frameworks. I definitely agree. > As a concrete example, I would like the data binding framework to provide > default controls with a default layout when creating a simple form for > entering data. Okay, here I think you've gone beyond my vision for version 1.0. I don't disagree, except perhaps in scope. In the simplest case, I don't think that a binding framework should have to care at all about layout managers or their ilk. However, it would be useful to be able to point some generic engine at an arbitrary POJO graph and have it automatically generate a UI for editing it, complete with layout managers, etc. But this is way beyond the scope I'm considering working on unless someone else wants to contribute it. :-) > However, it should be possible for the programmer to have > complete control over the layout and the controls, while still using > the "binding" part of the framework. That's exactly what I have proposed. The test application shows this: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ve.sweet/src/org/eclipse/ve/sweet/test/?cvsroot=Tools_Project TestSweet.java first uses regular SWT code to create the SWT UI, set properties, etc. It then calls the data binding framework to actually set up the editing. In response to Nick: Completely agree. I'm also not religious about the duck typing implementation. The DuckType dynamic proxy is very convenient and leads to very easy to read code, but you're right about the JVM level limitation. It should be possible to provide a version that is implemented using reflection and that has a reflection-like API so we can support back-level JVMs easily. comment #4 ---------------------------------------- “...I have business requirements for *today's* db4o applications that go beyond what is supplied by the JFace Viewer framework: - Keystroke-by-keystroke validation for plain Text fields. - Automatic selection of cell validators based on data type. - Validator definition using either plain Java code or using regular expressions (I use both). - Ability to override the built-in default validation with my own. - Ability to support any SWT control or JFace viewer with one code base “ ---------------------------------------- These are important logical requirements and we defiantly need to bring them into play. “…JFace by itself just wasn't designed to handle all this…” We need to provide extension to jFace interfaces to bind to objects/data. A (jFace) Viewer in particular is defined as following: /** * A viewer is a model-based adapter on a widget. … Though the viewer interfaces are not specific to SWT, the current viewers implementation is SWT literate: /** * Returns the primary control associated with this viewer. * * @return the SWT control which displays this viewer's content */ public abstract Control getControl(); Not doing so, would require reflection based code. ---------------------------------------- “I'm happy to consider other code bases as seed contributions than the one I contributed, but I *must* be able to replace the current Sweet code base with the same or better functionality for my existing customers. Otherwise, that's just a non-starter for me.” ---------------------------------------- I think that your code is a good seed but need to jFaceised a bit more ;-). ---------------------------------------- “Actually, the primary intent is to provide a single unified archiecture that can bind data to either JFace or SWT controls.” ---------------------------------------- The thing is that most of Eclipse based code today relies on viewers… having both a viewer and a bound IObjectViewer is kind of having two watches… hard to tell what the time is. ---------------------------------------- “But Eclipse itself is constructed of a mix of JFace and pure SWT controls because there aren't JFace wrappers for every SWT control.” ---------------------------------------- Just like the current sweet, we can implement a generic (SWT control) jFace wrapper. …. I can see you point that important properties like *text* are not common and may require some type of DuckType reflection Binding should not just to be a way to bind to a persistence store (with commit, rollback etc), but also to bind visuals (of a wizard page for example) to an object model, hooking it up to some page validation logic…. This will allow existing code to grow up and use this runtime support and hopfully significantly simplify it. It will be great if we can extend the current jFace interfaces, and implementing SWT base concrete code as much as possible. Btw… I updated the sweet code earlier to fix some bugs in order to allow the TestSweet example to run… have not changed anyting else ;-) > Okay, here I think you've gone beyond my vision for version 1.0.
This was just an example to illustrate my point, not a concrete suggestion of
what we need in a version 1.0.
Should we try to agree on a list of features we would like to see in a first
version?
So far I have seen the following:
- binding to SWT text controls
- binding to JFace table viewers
- providing generic editing support for tables
- keystroke-by-keystroke validation
- configurable validators
There must be more... ;-)
(In reply to comment #10) > I think that your code is a good seed but need to jFaceised a bit more ;-). I'd be happy to consider specific suggestions. > ---------------------------------------- > “Actually, the primary intent is to provide a single unified archiecture that > can bind data to either JFace or SWT controls.” > ---------------------------------------- > > The thing is that most of Eclipse based code today relies on viewers… having > both a viewer and a bound IObjectViewer is kind of having two watches… hard to > tell what the time is. I don't see how we're going to get around this because: 1) JFace is Eclipse Platform-Quality API, so we can't change it. We have to maintain it for backward compatibility. 2) In addition to the requirements I have described before, I have a firm requirement for being able to generically bind to multiple types of back-ends, even within a single application. Here is an incomplete but representative list: JavaBean-style POJOs, EMF objects, db4o databases, Hibernate-persisted databases, Prevayler-persisted objects (both embedded and remote through a custom RMI-like server). Being able to bind to any of these things requires building an abstraction API that necessarily introduces the need to support (1) transactions, (2) local versus remote objects, (3) model-driven constraint definition, by which I mean that the engine has to be able to get an IValidator from a business model object for a given property--and the object may even physically be across the network somewhere. Network transparancy and abstracted transactions (to name just two of the major issues you have to deal with when you're doing this) are things the current JFace API just doesn't support directly. To support these ideas elegantly requires new abstractions which in turn implies new API. > ---------------------------------------- > “But Eclipse itself is constructed of a mix of JFace and pure SWT controls > because there aren't JFace wrappers for every SWT control.” > ---------------------------------------- > > Just like the current sweet, we can implement a generic (SWT control) jFace > wrapper. …. I can see you point that important properties like *text* are not > common and may require some type of DuckType reflection > > > Binding should not just to be a way to bind to a persistence store (with commit, > rollback etc), but also to bind visuals (of a wizard page for example) to an > object model, hooking it up to some page validation logic…. This will allow > existing code to grow up and use this runtime support and hopfully significantly > simplify it. The existing Sweet design can do exactly this. There are opportunities to link it more tightly with the wizard page framework, though. I personally see that as a v1.5 feature though. I suggest we get basic data binding right, then we can see how we can improve it for specific common use-cases. > It will be great if we can extend the current jFace interfaces, > and implementing SWT base concrete code as much as possible. I don't think we fundamentally disagree here on our goals. I'm just at a point where I think I need specific suggestions about how the current code could be improved to do this more. The framework is designed to work well with JFace the way it is today, but I very well might have missed some opportunity for closer integration. So by all means, please see if you can identify areas where we can integrate it better. > Btw… I updated the sweet code earlier to fix some bugs in order to allow the > TestSweet example to run… have not changed anyting else ;-) Cool, thanks! I must have broken something along the way. ----- Replying to Boris: So to summarize the new requirements listed above: (these exist today in a new application I'm building): - Bind to any kind of object anywhere. Here are a few examples of the kinds of objects I mean: * RMI objects * Remote objects through a custom server * JavaBean style local objects * EMF objects (local) * Objects retrieved dynamically via Hibernate, some caching solution, or db4objects - If the back-end data store supports transactions, automatically use them. * For example, TableViewer should automatically call commit() when the user leaves a row. Or it could automatically call rollback() when the user hits <ESC> I should clarify: I use Sweet's capability to transparently bind to POJOs and/or db4o objects in the same application today. But if you do this much, you wind up getting most of the infrastructure for the others along the way. I think that the best way to continue is drive another crank on the current code base. Our thinking is to create Editor based jFace components that extend the current “Viewer” (metaphor) hierarchy; where the extended Editor accepts a special content/label providers that know how to provide data from an input, as well as to receive and update that editor’s input. The “ commit() on leave a row..” kind of thing can be addressed with some kind of Editor update policies (e.g., immediate - when key, for example, is pressed, focus is lost, explicit – e.g., explicit call from code; Update button is pressed for example) to make it more generic. Note that the sweet project will now look for two User Libraries to compile (see org.eclipse.ve.sweet/src/org/eclipse/ve/sweet2/hibernate/README.html). You can always remove the following lines from the .classpath if you want to compile the project without the hibernate based example: <classpathentry kind="con" path="org.eclipse.jdt.USER_LIBRARY/Hibernate"/> <classpathentry kind="con" path="org.eclipse.jdt.USER_LIBRARY/DBclient"/> Might I suggest looking into the SWT port of JGoodies Binding. It is simple yet very powerful. It uses the standard ValueModel concepts often found in data binding. I know the Spring RCP team has already forked the JGoodies code for their uses. An Eclipse sponsored version of the link below might be a good step. http://www.jayasoft.fr/org/modules/swtbinding/overview.php? (In reply to comment #16) > Might I suggest looking into the SWT port of JGoodies Binding. <snip/> I've looked at it and think it's nice, but that it doesn't solve all the problems I'd like to see solved: - Transactional awareness when editing database-backed data - Using and extending JFace when and where possible We're working on a framework that will solve these requirements and more. For more details, please see the code in dev.eclipse.org as specified above. Created attachment 26993 [details] SWT Binders To move this effort forward, we have attached a SWT bindings proposal. We intend to discuss these requirements/starting point with the following eMeeting conference call Thursday, Sep. 15th, at 10:00 ET http://www.timeanddate.com/worldclock/converted.html?month=9&day=15&year=2005&hour=0&min=0&sec=0&p1=207&p2=0 The call/meeting has 20 slots, which is more than the (at this time) .cc on this defect. If you can share connections from a conference rooms, it will enable more folks to join in. JOIN THE WEB CONFERENCE 1) Join the conference up to 15 minutes prior to 9/15/2005 10:00 AM (UTC -4) 2) Direct your web browser to the following URL: https://www.ibm.com/collaboration/webconferences/meetingdetails.jsp?meetingId=E00A4A216CB0F94159AFCAD0FD7B6428 3) When asked, enter your user name and password. Customers use your IBM ID. 4) When prompted, enter the web conference password: ecl1pse Additional web conference details: Conference name: SWT Bindings Password: ecl1pse Start time: 9/15/2005 10:00 AM (UTC -4) Duration: 2h 0m To get an ID, use the following URL: https://www-1.ibm.com/collaboration/collaboratenow/ Telephone: USA Toll Free Number: 888-322-7148 USA Toll Number: +1-210-234-8003 International: +1-210-234-8003 PASSCODE: 54551 JFace Binders Meeting Minutes: Attendees: Dave Orme (VE Lead / Coconut Palm Software) Michael Van Meekeren (JFace / IBM) Boris Bokowski (JFace / IBM) Dr Gili Mendel (VE / IBM) Peter Walker (VE / IBM) Rich Kulp (VE / IBM) Srimanth Gunturi (VE / IBM) Joe Winchester (VE / IBM) Seth Packham/Durham (IBM) Michael Stokes (IBM) Richard A Bone (IBM) George DeCandio (IBM) 9:05 AM CDT -- Dave Orme opened meeting and introduced Gili 9:06 AM - 10:15 AM -- Gili presented slides linked in comment 18 and ran demos 10:15 AM - 10:20 AM -- Gili wrapped up and asked if we had consensus that this presentation describes what we want to do Michael agreed, but said that they would like to iterate on the API some. 10:20 AM - 10:23 AM -- Gili said that Dave Orme would drive the effort going forward. Dave suggested that if there are parts of the design that are not controversial at this time that perhaps he could start implementing a first cut of those. Michael said he would prefer to go through the technical feedback process first. Dave agreed that this approach is fine. We then agreed that Michael would let the entire team know when the JFace team is prepared with their feedback, Gili would allocate a conference call line, and Dave would set up a VNC server to host the next meeting next week. The meeting was adjorned. -------- This was written down from memory immediately after the meeting. If anyone remembers anything important that I left out, please follow up with a comment. Created attachment 27343 [details]
Word document describing a simple data binding API
This document describes the direction we would like to take with regards to
data binding. More complicated scenarios (tables, master/detail) are not yet
covered, but we are working on it. Comments welcome!
*** Bug 5013 has been marked as a duplicate of this bug. *** Created attachment 27394 [details]
Powerpoint slides
slides for the conference call on 2005/09/22
[Gili wrote via email]
-------
Tks, Boris/Michael for the presentation. I must say that we are all quite
impressed with your proposal and will be more than happy to help push it forward.
The following are the things I wrote down, and that may need some more iteration on:
Dispose
The current assumption that the target is a Widget... this may not always be
the case.
It will be preferable for the IUpdatable impl. do the cleanups implicitly.
Delegate
Currently the IUpdatable binds to an Object's property... no mechanism to
bind to a property of a variable:
In the sample app. The Combo's text was bounded to a TextField's text...
this is a nice example, but not really practical.
A Combo does not have a notion of a model... (e.g., ComboViewer)
Typically a combo selections selects an Object, say a Person. Other elements
are then bounded to a property of the selected Person.
Up front, there are two ways to achieve this:
1. IUpdatable has a notion (and can change) the "root" object, given that
it is already a wrapper.
2. IUpdatable can be the object of an IUpdatable ....and use nesting to
bind to a property of an IUpdatable.
TableViewer vs UpdatableList
JFace vs. Binders.... is it one, the other, both???? .... goal should be not
to replace JFace... even of someone is writing a new visual, it is likely to be
a part of, or interact with existing JFace components.... keep the usage the
same/familiar as much as possible.
naming:
IUpdatableList.getSize->getElementCount .... make it more like JFace
IUPdateTable.getColumnTypes() -> getColumnType(int)
BindingService interface
Need a mechanism to know that the BindingService object is that type of a
service (interface, abstract...)
Scenario.
Need to agree on the scenario, can use the first presentations ... they
comprise most of what it takes to build a full app.
target is early next week
Customization issues
How will one get down to "turn knobs" of IUpdatable impls. that are created
behind the curtains. .. settings on the factory ???
Creating/Extending/Contributing to Service/ServiceFactories
Need a generic, single (as much as possible) boiler plate coding/discovering.
(In reply to comment #23) > [Gili wrote via email] > ------- > > Tks, Boris/Michael for the presentation. I must say that we are all quite > impressed with your proposal and will be more than happy to help push it forward. > > The following are the things I wrote down, and that may need some more iteration on: > > Dispose > The current assumption that the target is a Widget... this may not always be > the case. > It will be preferable for the IUpdatable impl. do the cleanups implicitly. Gili, Sweet could get away with always using a dispose listener because it has a concept of setInput(), and you only ever bind a single object to a given control. This proposal can't use that solution because you need a new IUpdateable object every time you want to set a new input on a control. So the dispose() method (maybe misnamed) is really just unregistering all of its event handlers and you can't get away from that. > Delegate > Currently the IUpdatable binds to an Object's property... no mechanism to > bind to a property of a variable: Not sure what you mean here. Either a variable references an object, in which case it makes total sense to bind to a property of the object, or it contains a primitive type. So far, no binding proposal we have considered handles this use-case, so we're all even there. Am I missing something? > In the sample app. The Combo's text was bounded to a TextField's text... > this is a nice example, but not really practical. Maybe in this example. But there are times when you would want to bind the selected property of a check box to the enabled property of a push button, for example. This sort of thing happens all the time in user interfaces. > Typically a combo selections selects an Object, say a Person. Other elements > are then bounded to a property of the selected Person. > Up front, there are two ways to achieve this: > > 1. IUpdatable has a notion (and can change) the "root" object, given that > it is already a wrapper. > 2. IUpdatable can be the object of an IUpdatable ....and use nesting to > bind to a property of an IUpdatable. I prefer #2--to build out the framework using itself. > TableViewer vs UpdatableList > > JFace vs. Binders.... is it one, the other, both???? .... goal should be not > to replace JFace... even of someone is writing a new visual, it is likely to be > a part of, or interact with existing JFace components.... keep the usage the > same/familiar as much as possible. I'll let Boris / the JFace team reply to this. > naming: > IUpdatableList.getSize->getElementCount .... make it more like JFace > IUPdateTable.getColumnTypes() -> getColumnType(int) Personally, I think we should stay as close as possible to Java collections framework naming conventions. Java programmers as a whole are more familiar with Java collections framework naming conventions than JFace naming conventions and I think it's safe to say that every JFace programmer is already fluent with the Java collections naming conventions. So if we stick with Java Collections naming conventions, *nobody* has to learn anything new. If we go with JFace-specific naming conventions, then we make it harder than it should be necessary for non-Eclipse programmers to learn the binding framework. I vote to keep Boris's current naming. > BindingService interface > Need a mechanism to know that the BindingService object is that type of a > service (interface, abstract...) What is the use-case for this? > Scenario. > > Need to agree on the scenario, can use the first presentations ... they > comprise most of what it takes to build a full app. > target is early next week > > Customization issues > How will one get down to "turn knobs" of IUpdatable impls. that are created > behind the curtains. .. settings on the factory ??? Boris, this relates to how we eventually implement the whole thing. I would be most comfortable (since I'll be maintaining this code long-term anyway) building your API into Sweet 0. If this is true, one would customize behavior using the registries that Sweet 0 defines (to answer Gili's question). Of course, I'm open to naming/structure changes before we declare what is API and decide how everything will ultimately work. Is this in line with your thoughts or do you have a different idea? > Creating/Extending/Contributing to Service/ServiceFactories > Need a generic, single (as much as possible) boiler plate > coding/discovering. Yes. > Delegate > Currently the IUpdatable binds to an Object's property... no mechanism to > bind to a property of a variable: Not sure what you mean here. Either a variable references an object, in which case it makes total sense to bind to a property of the object, or it contains a primitive type. So far, no binding proposal we have considered handles this use-case, so we're all even there. Am I missing something? --- Take the case of a the selected entry of a list box of people determines the person that will be displayed in a text field. In this case the text field would be bound to the "name" attribute of the selected person. But at bind time we don't know who the selected person is. It is constantly changing. So you would instead bind to the "name" attribute of an IUpdateValue (call them Person and PersonsName IUpdatableValues) that wrappers the selected person. The selection of the listbox will be bound to the Person IUpdateValue. Now whenever the selection changes a new person is set into the Person IUpdatableValue, this then lets the PersonsName IUpdatableValue be changed to the new name and so the text field get's the new name. > BindingService interface > Need a mechanism to know that the BindingService object is that type of a > service (interface, abstract...) --- For visual tooling purposes. It is very difficult to guess that this is binding two objects. It could easily be wrong. Since we are providing some interfaces already, it is just a simple step to provide one more. (In reply to comment #25) > > Delegate > > Currently the IUpdatable binds to an Object's property... no mechanism to > > bind to a property of a variable: > > Not sure what you mean here. Either a variable references an object, in which > case it makes total sense to bind to a property of the object, or it contains a > primitive type. So far, no binding proposal we have considered handles this > use-case, so we're all even there. > > Am I missing something? > > --- Take the case of a the selected entry of a list box of people determines the > person that will be displayed in a text field. In this case the text field would > be bound to the "name" attribute of the selected person. But at bind time we > don't know who the selected person is. It is constantly changing. So you would > instead bind to the "name" attribute of an IUpdateValue (call them Person and > PersonsName IUpdatableValues) that wrappers the selected person. The selection > of the listbox will be bound to the Person IUpdateValue. Now whenever the > selection changes a new person is set into the Person IUpdatableValue, this then > lets the PersonsName IUpdatableValue be changed to the new name and so the text > field get's the new name. Okay, I think I follow this but I'm not sure I understand what the question is. > > BindingService interface > > Need a mechanism to know that the BindingService object is that type of a > > service (interface, abstract...) > > --- For visual tooling purposes. It is very difficult to guess that this is > binding two objects. It could easily be wrong. Since we are providing some > interfaces already, it is just a simple step to provide one more. > Thanks, I understand now. :-) *** Bug 74368 has been marked as a duplicate of this bug. *** Just to confirm, Dave (and everyone else) I'm assuming we don't need to have the call this week. It seems like there has been lots of dialog between Boris, Joe, Gili and yourself. I suggest that next week we might want to have one. Thoughts? (In reply to comment #28) > Just to confirm, Dave (and everyone else) I'm assuming we don't need to have the > call this week. It seems like there has been lots of dialog between Boris, Joe, > Gili and yourself. Agreed. Boris and I paired on this on Tuesday and I expect we will continue tonight. I understand that Gili and his team are working with Boris too. > I suggest that next week we might want to have one. Good idea. I am interested in monitoring the progress of this work. Whenis it going to be available in production quality? Thanks! (In reply to comment #30) > I am interested in monitoring the progress of this work. Whenis it going to be > available in production quality? Thanks! Eclipse 3.2. I haven't read over all this yet, but I'd like to see whatever is decided upon be comparable with the nice data binding support that MS put into WinForms, the new Grid controls, and Avalon. I like the way they can do disconnected data sources, XML files, flat files, and databases all with the same interface. The simplicity for the coder is also nice in their solution. One thing I don't understand from what I've read so far is the support for plain SWT controls. Binding seems like a concern of JFace or above and not the widget layer. (In reply to comment #32) > I haven't read over all this yet, but I'd like to see whatever is decided upon > be comparable with the nice data binding support that MS put into WinForms, the > new Grid controls, and Avalon. I like the way they can do disconnected data > sources, XML files, flat files, and databases all with the same interface. The > simplicity for the coder is also nice in their solution. We think we've come up with an even simpler interface than what Microsoft has done for accomplishing all of what you describe. > One thing I don't understand from what I've read so far is the support for plain > SWT controls. Binding seems like a concern of JFace or above and not the widget > layer. This is one important area where we're different from Microsoft's solution. Microsoft's solution requires special "data-aware" controls. We have no such requirement--we'll work with *any* control. We view binding as orthogonal to UI concerns. Binding at its simplest level is just connecting a property of one object to a property of another object such that changes to one are automatically reflected in the other. The fact that some of those objects might be JFace or SWT controls (or even Swing controls) is incidental. Please read Boris's paper (Attachment: "Word document describing a simple data binding API" above) for more details. Our implementation has changed somewhat since then, but the basic ideas are still the same. For those tracking progress here, the data binding framework (which is marked as *experimental* API) is now included in the Eclipse nightly builds. If you try it and need to enter bugs against it, please add the tag [DataBinding] to the front of the summary so that we will find it quickly. In addition, if you're feeling really energetic, we'll find it even faster if you add myself, Boris, or Joe Winchester to the CC list. ;-) (In reply to comment #34) > For those tracking progress here, the data binding framework (which is > marked as *experimental* API) is now included in the Eclipse nightly builds. It also available in I20051115-0800 and later. A (work-in-progress) document describing the data binding framework is available at this URL: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui-home/databinding-proposal/databinding.html I will add another comment to this bug when the document has stabilized a bit. I think I found problem with this version: eclipse-SDK-I20051116-1332-win32.zip
When I try to bind "double" property to Text it throws exception:
org.eclipse.jface.databinding.BindingException: Converter does not apply to
model type. Expected: double, actual: class java.lang.String
at org.eclipse.jface.databinding.internal.ValueBinding.<init>(ValueBinding.java:61)
at
org.eclipse.jface.databinding.internal.DataBindingContext.bind(DataBindingContext.java:399)
at
org.eclipse.jface.databinding.internal.DataBindingContext.bind(DataBindingContext.java:454)
at
org.eclipse.jface.databinding.internal.DataBindingContext.bind(DataBindingContext.java:511)
at ru.nlmk.Test.createContents(Test.java:87)
at ru.nlmk.Test.open(Test.java:45)
at ru.nlmk.Test.main(Test.java:34)
I am not sure, but problem can be in ValueBinding, because when I change this:
if (!converter.getModelType().equals(model.getValueType())) {
throw new BindingException(
"Converter does not apply to model type. Expected: " + model.getValueType()
+ ", actual: " + converter.getModelType()); //$NON-NLS-1$ //$NON-NLS-2$
}
if (!converter.getTargetType().equals(target.getValueType())) {
throw new BindingException(
"Converter does not apply to target type. Expected: " +
target.getValueType() + ", actual: " + converter.getTargetType()); //$NON-NLS-1$
//$NON-NLS-2$
}
to this:
if (!converter.getTargetType().equals(model.getValueType())) {
throw new BindingException(
"Converter does not apply to model type. Expected: " + model.getValueType()
+ ", actual: " + converter.getTargetType()); //$NON-NLS-1$ //$NON-NLS-2$
}
if (!converter.getModelType().equals(target.getValueType())) {
throw new BindingException(
"Converter does not apply to target type. Expected: " +
target.getValueType() + ", actual: " + converter.getModelType()); //$NON-NLS-1$
//$NON-NLS-2$
}
it works.
See also source code for bean and GUI below.
import java.beans.PropertyChangeListener;
import java.beans.PropertyChangeSupport;
public class User {
private String m_firstName;
private String m_lastName;
private double m_age;
private PropertyChangeSupport m_propertyListeners = new PropertyChangeSupport(
this);
public String getFirstName() {
return m_firstName;
}
public void setFirstName(String firstName) {
m_firstName = firstName;
}
public String getLastName() {
return m_lastName;
}
public void setLastName(String lastName) {
String oldLastName = m_lastName;
m_lastName = lastName;
m_propertyListeners.firePropertyChange("lastName", oldLastName,
m_lastName);
}
public double getAge() {
return m_age;
}
public void setAge(double age) {
Double oldAge = new Double(m_age);
m_age = age;
m_propertyListeners
.firePropertyChange("age", oldAge, new Double(m_age));
}
@Override
public String toString() {
return "(" + m_firstName + ", " + m_lastName + ", " + m_age + ")";
}
public void addPropertyChangeListener(PropertyChangeListener listener) {
m_propertyListeners.addPropertyChangeListener(listener);
}
public void removePropertyChangeListener(PropertyChangeListener listener) {
m_propertyListeners.removePropertyChangeListener(listener);
}
}
import org.eclipse.jface.databinding.DataBinding;
import org.eclipse.jface.databinding.IDataBindingContext;
import org.eclipse.jface.databinding.PropertyDescription;
import org.eclipse.swt.SWT;
import org.eclipse.swt.events.SelectionAdapter;
import org.eclipse.swt.events.SelectionEvent;
import org.eclipse.swt.layout.GridData;
import org.eclipse.swt.layout.GridLayout;
import org.eclipse.swt.widgets.Button;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;
import org.eclipse.swt.widgets.Text;
public class Test {
private Text m_txtAge;
private Text m_txtLast;
private Text m_txtFirst;
protected Shell shell;
/**
* Launch the application
*
* @param args
*/
public static void main(String[] args) {
try {
Test window = new Test();
window.open();
} catch (Exception e) {
e.printStackTrace();
}
}
/**
* Open the window
*/
public void open() {
final Display display = Display.getDefault();
createContents();
shell.open();
shell.layout();
while (!shell.isDisposed()) {
if (!display.readAndDispatch())
display.sleep();
}
}
/**
* Create contents of the window
*/
protected void createContents() {
shell = new Shell();
shell.setLayout(new GridLayout());
shell.setSize(439, 312);
shell.setText("SWT Application");
final User user = new User();
user.setFirstName("Konstantin");
user.setLastName("Scheglov");
user.setAge(12);
System.out.println("before: " + user);
m_txtFirst = new Text(shell, SWT.BORDER);
m_txtFirst.setLayoutData(new GridData(GridData.FILL, GridData.CENTER,
true, false));
m_txtLast = new Text(shell, SWT.BORDER);
m_txtLast.setLayoutData(new GridData(GridData.FILL, GridData.CENTER,
true, false));
m_txtAge = new Text(shell, SWT.BORDER);
m_txtAge.setLayoutData(new GridData(GridData.FILL, GridData.CENTER,
true, false));
IDataBindingContext bindingContext = DataBinding.createContext(shell);
try {
bindingContext.bind(m_txtFirst, new PropertyDescription(user,
"firstName"), null);
bindingContext.bind(m_txtLast, new PropertyDescription(user,
"lastName"), null);
bindingContext.bind(m_txtAge, new PropertyDescription(user, "age"),
null);
} catch (Throwable e) {
e.printStackTrace();
}
final Button showButton = new Button(shell, SWT.NONE);
showButton.addSelectionListener(new SelectionAdapter() {
public void widgetSelected(SelectionEvent e) {
System.out.println("current: " + user);
}
});
showButton.setLayoutData(new GridData(GridData.FILL, GridData.CENTER,
true, false));
showButton.setText("Show!");
final Button changeButton = new Button(shell, SWT.NONE);
changeButton.addSelectionListener(new SelectionAdapter() {
public void widgetSelected(SelectionEvent e) {
user.setLastName("" + System.currentTimeMillis());
user.setAge(18);
}
});
changeButton.setLayoutData(new GridData(GridData.FILL, GridData.CENTER,
false, false));
changeButton.setText("Change!");
}
}
Konstantin, thank you for experimenting with the data binding framework. I have opened bug 116862 for the problem you describe. Everyone, please open separate bugzillas against Platform UI with [DataBinding] in the title for problems, concerns, bugs, or enhancement requests. I intend to close this bug once the documentation and API has stabilized a bit. I create a databinding related feature request: bug 118125 [databinding] databinding needs support for editors with undoable commands Could someone add the string [DataBinding] to the summary of this bug. Search for DataBindung in summary finds all kinds of bugs, but not this one. Has anyone planned to give a talk about the databinding framework at eclipsecon? If not, I am considering to give a talk titled: "Simplify EMF editors with the new jface databinding framework and annotation driven GUI layout" I have submitted a talk: http://canuck.gda.itesm.mx/eclipsezilla/show_bug.cgi?id=89 I am pleased to announce that where I am currently consulting, we are now using the new JFace data binding framework for a large-scale project. I have proposed a new EclipseCon talk to present the lessons we learn from applying this new technology to a real-world project. See: http://canuck.gda.itesm.mx/eclipsezilla/show_bug.cgi?id=271 If you like it, please vote for it. :-) i think this code is an ongoing effort based on the essential data things ? I have had a short look into the specification document attached here, and i would like to have it done in more details before go on with coding, because i think that "things" should be more clear on what to do and on how to do. basically a review and compatibilty to other efforts on swing, html, apache commons etc should be done. what i miss are things like: -> what is done with auto completion of user input, before validation. -> validators: there could be more so there sould be a chain of them ? -> what´s about exception handling -> whats with message display and notification. -> model change notification and the view -> cross field validation -> undo/redo -> what about marking a field dirty, and when to clean it -> if validation gets wrong, is it saved to the model or not, what is left in the ui-field ? -> for all those message notifications about model changes there may be some problems of getting into circles and un-whanted depencencies. -> auto completition, formating to a type and basic validation of a type has some close behaviour. -> essential data was havily based on reflection. there are pros and cons about that. as we also need such a framework we are interested in giving you feedback and may be able to contribute some small parts. good luck, a good binding framework will improve swt and jface a lot ;-) Thanks for the feedback. Comments inline: (In reply to comment #44) > i think this code is an ongoing effort based on the essential data things ? The JFace binding design is a totally new design done by Boris, who I'm sure looked at Essential Data or another framework I wrote that was pretty similar to Essential Data. It's different from ED in some important ways so if you're used to ED, there will be a slight learning curve until you get used to the new way of thinking about binding. > I have had a short look into the specification document attached here, and i > would like to have it done in more details before go on with coding, because i > think that "things" should be more clear on what to do and on how to do. We agree. Documentation right now is severely lacking. But then, we have a February API freeze deadline we have to beat, so I don't expect Docs to change much before then. > basically a review and compatibilty to other efforts on swing, html, apache > commons etc should be done. > > what i miss are things like: > -> what is done with auto completion of user input, before validation. This would be a custom SWT control. If someone writes one, we can bind to it. > -> validators: there could be more so there sould be a chain of them ? Can you be more explicit here? Of course, you can write a validator that delegates to another validator, but I'm not sure that's what you mean. > -> what´s about exception handling Again, I'm not sure what you're looking for here. > -> whats with message display and notification. This is more flexible than ED. ED had a singleton that provided message display events. We provide an IUpdatableValue on the data binding context, which gives much finer granularity. > -> model change notification and the view We support JavaBeans (POJOS) out of the box but with a simpler syntax than ED used. > -> cross field validation This is bug #119504. > -> undo/redo Bug #116465. Simple to implement, once we fix a dependent bug. > -> what about marking a field dirty, and when to clean it 119791 > -> if validation gets wrong, is it saved to the model or not, what is left in > the ui-field ? Configurable based on how you write your validators. What behavior do you need? > -> for all those message notifications about model changes there may be some > problems of getting into circles and un-whanted depencencies. We haven't seen this yet. If you find this, please file a bug with a test case. > -> auto completition, formating to a type and basic validation of a type has > some close behaviour. ...not to mention picture strings and so on... > -> essential data was havily based on reflection. there are pros and cons > about that. Our default implementation is based on reflection. But our implementation is completely open, so you can replace any of this behavior you need or want to. > as we also need such a framework we are interested in giving you feedback and > may be able to contribute some small parts. > good luck, a good binding framework will improve swt and jface a lot ;-) Thanks! Look forward to seeing you around. >> ... >> think that "things" should be more clear on what to do and on how to do. > We agree. Documentation right now is severely lacking. But then, we have a > February API freeze deadline we have to beat, so I don't expect Docs to change > much before then. I am not talking about any documentation, i am talking about a more detailed specification document about what should be coded and e.g. what are the designed event flows etc... >> what i miss are things like: >> -> what is done with auto completion of user input, before validation. > This would be a custom SWT control. If someone writes one, we can bind to it. well i think that this should be included in the standardard framework, because the automatic completition of some user input is not that un-usual. think of a date input control, the user may enter 10 and the output may be May 10 2005 or something else, any immediate validation would fail on 10 to be a date, our would have to accept this. >> -> validators: there could be more so there sould be a chain of them ? > Can you be more explicit here? Of course, you can write a validator that > delegates to another validator, but I'm not sure that's what you mean. yes, we can. well for validators i do think there should be a standard validator that ensures that it is the propper type, and then there could be other more specific ones, e.g. date-ranges, bank/working day, is-not-null (In reply to comment #46) > >> ... > >> think that "things" should be more clear on what to do and on how to do. > > We agree. Documentation right now is severely lacking. But then, we have a > > February API freeze deadline we have to beat, so I don't expect Docs to change > > much before then. > > I am not talking about any documentation, i am talking about a more detailed > specification document about what should be coded and e.g. what are the > designed event flows etc... We're following an agile process here--which means we have enough design documentation so that any of us can read the code and understand it. After that, we discuss what needs to be done and implement it. Most of our formal discussion currently is on Bugzilla in the bugs with [DataBinding] in the summary. That is where the details of the design and implementation are being fleshed out iteratively. If there's something specific you'd like to know about, please ask; we'd be happy to help. > >> what i miss are things like: > >> -> what is done with auto completion of user input, before validation. > > This would be a custom SWT control. If someone writes one, we can bind to it. > > well i think that this should be included in the standardard framework, because > the automatic completition of some user input is not that un-usual. think of a > date input control, the user may enter 10 and the output may be May 10 2005 or > something else, any immediate validation would fail on 10 to be a date, our > would have to accept this. I agree that this would be nice. All the current committers are maxed out on their time right now, so if somebody would like to write such a control, it would be a very cool thing to include! > >> -> validators: there could be more so there sould be a chain of them ? > > Can you be more explicit here? Of course, you can write a validator that > > delegates to another validator, but I'm not sure that's what you mean. > > yes, we can. well for validators i do think there should be a standard > validator that ensures that it is the propper type, and then there could be > other more specific ones, e.g. date-ranges, bank/working day, is-not-null We do this today. Thanks again for the feedback! (In reply to comment #46) > >> -> validators: there could be more so there sould be a chain of them ? > > Can you be more explicit here? Of course, you can write a validator that > > delegates to another validator, but I'm not sure that's what you mean. > > yes, we can. well for validators i do think there should be a standard > validator that ensures that it is the propper type, and then there could be > other more specific ones, e.g. date-ranges, bank/working day, is-not-null I thought some more about what you are saying and filed bug #104570 as a result. Thanks! (In reply to comment #48) > (In reply to comment #46) > > >> -> validators: there could be more so there sould be a chain of them ? > > > Can you be more explicit here? Of course, you can write a validator that > > > delegates to another validator, but I'm not sure that's what you mean. > > > > yes, we can. well for validators i do think there should be a standard > > validator that ensures that it is the propper type, and then there could be > > other more specific ones, e.g. date-ranges, bank/working day, is-not-null > > I thought some more about what you are saying and filed bug #104570 as a > result. Thanks! Sorry, that was bug #120582. :-} How's this relate to bug 106199 (improved assistance in text fields)? If they don't relate now, can they? (In reply to comment #50) > How's this relate to bug 106199 (improved assistance in text fields)? If they > don't relate now, can they? > Please see also bug 106199, comment #29. :-) expounding a bit on the relationship between data binding and the field assist work... It would be great to have a high-level example of a form or dialog that uses: - data binding - field decorations for required field indication - content proposals for auto-completion of fields - validators that can use either decorations or the normal status message to show error conditions (decorations if field-based cues are desired) - special input validating controls to demonstrate that the decorations and content proposal adapters can operate on arbitrary controls For different app frameworks, these tools will be combined in different ways, with different decisions about how errors, required fields, etc. are shown, and how much validation occurs before updating the model. I don't see a lower-level tie-in of these building blocks. Anyone who has time to take a stab at this - it would be appreciated as a way to validate that all of these work together as well as we claim they should... ;-) (In reply to comment #52) > expounding a bit on the relationship between data binding and the field assist > work... It would be great to have a high-level example of a form or dialog that > uses: > - data binding > - field decorations for required field indication > - content proposals for auto-completion of fields > - validators that can use either decorations or the normal status message to > show error conditions (decorations if field-based cues are desired) > - special input validating controls to demonstrate that the decorations and > content proposal adapters can operate on arbitrary controls > > For different app frameworks, these tools will be combined in different ways, > with different decisions about how errors, required fields, etc. are shown, and > how much validation occurs before updating the model. I don't see a > lower-level tie-in of these building blocks. > > Anyone who has time to take a stab at this - it would be appreciated as a way > to validate that all of these work together as well as we claim they should... > ;-) I want to add Decoration to the controls I use with Databinding framework. It's hard to do, because Validators don't have the control visibility (target) (see IValidator interface). Then, I thought I could create a new IDatabindingContext implementation and addFieldDecoration here, but I couldn't, since in updateValidationError() method, I don't have visibility of the control. I think it can be useful to have target visibility in Validator or DatabindingContext. Is there an other way to link Validation/Conversion and Decoration ? Will the API change to enable decoration capability ? Nicolas - thanks for trying this out, it's really important for us to resolve any API issue that would prevent these two features from working well together. Is there a simple example that you could attach? Might help in discussing the issues. Can a data binding person comment on this? From a field decoration standpoint, you need to have a reference to the DecoratedField in order to hide/show decorations or add decorations. From that field, you can also get access to the control itself. (In reply to comment #54) > Can a data binding person comment on this? From a field decoration standpoint, > you need to have a reference to the DecoratedField in order to hide/show > decorations or add decorations. From that field, you can also get access to > the control itself. This is a symptom of bug #120582. I am currently working on a solution to this; all suggestions are also welcome. I have looked at JGoodies bind- and validation- framwork. I recognized that the org.eclipse.jface.databinding.validator.IValidator can only report one message. JGoodies supports several messages and in addition a serverity. http://www.google.ch/search?hl=de&q=IValidator+binding+jface+api&btnG=Suche&meta= re comment #56: yes - see bug 118429. With M5 being declared soon, I would like to give you an update on the JFace data binding framework. We have decided to *not* publish the data binding framework as official API for 3.2 because it has not yet received sufficient review and/or adoption. In particular, we were not confident that the listener notification API was sufficiently stable. Since we made the decision, we have been busy refactoring the framework to address our concerns. The result of this refactoring will be released into HEAD next week. The main changes were (0) renaming packages to internal.provisional, (1) renaming IUpdatable to IObservable, (2) restructuring the IObservable hierarchy, (3) the way listeners are registered and notified, and (4) switching back to one-way converters. I will send instructions for migrating from the current framework to the refactored version when I release it to HEAD. In a nutshell, (0) and (1) are simple renames, (4) is more or less mechanical, and (2) and (3) only affect you if you are currently implementing IUpdatable or listening directly to an IUpdatable. After the dust settles (i.e. in a few weeks), we will try to evolve the provisional "API" in an upwards-compatible way as much as possible to give early adopters a chance to use it for real. To this end, we will remove the current "EXPERIMENTAL" warnings. However, it is important to remember that when the framework is promoted to real API, there will be a porting effort for existing clients. In the best case this porting effort amounts to an organize imports on your source files, but obviously we cannot promise that this is going to be all. Thanks Boris Bokowski (In reply to comment #58) > With M5 being declared soon, I would like to give you an update on the JFace > data binding framework. > > We have decided to *not* publish the data binding framework as official API for > 3.2 because it has not yet received sufficient review and/or adoption. In > particular, we were not confident that the listener notification API was > sufficiently stable. > > Since we made the decision, we have been busy refactoring the framework to > address our concerns. The result of this refactoring will be released into > HEAD next week. The main changes were (0) renaming packages to > internal.provisional, (1) renaming IUpdatable to IObservable, (2) restructuring > the IObservable hierarchy, (3) the way listeners are registered and notified, > and (4) switching back to one-way converters. I will send instructions for > migrating from the current framework to the refactored version when I release > it to HEAD. In a nutshell, (0) and (1) are simple renames, (4) is more or less > mechanical, and (2) and (3) only affect you if you are currently implementing > IUpdatable or listening directly to an IUpdatable. > > After the dust settles (i.e. in a few weeks), we will try to evolve the > provisional "API" in an upwards-compatible way as much as possible to give > early adopters a chance to use it for real. To this end, we will remove the > current "EXPERIMENTAL" warnings. However, it is important to remember that > when the framework is promoted to real API, there will be a porting effort for > existing clients. In the best case this porting effort amounts to an organize > imports on your source files, but obviously we cannot promise that this is > going to be all. > > Thanks > Boris Bokowski > I started my development with M5 databinding API. I want to migrate to M6. After refactoring, it seems to be ok, but I have lost the functionality of table binding with read-write mode. I can bind a read only table, but not write with editors, converters... I saw there has been a refactoring with TableModelDescription. Can you give me more info regarding your strategy. Will write mode be implemented later? Should I port the M5 tableViewer binding to M6? What will be provided in final release in june? What would be the more stable way to implement a workaround? Thanks for your reply. > I started my development with M5 databinding API. I want to migrate to M6.
> After refactoring, it seems to be ok, but I have lost the functionality of
> table binding with read-write mode. I can bind a read only table, but not write
> with editors, converters... I saw there has been a refactoring with
> TableModelDescription. Can you give me more info regarding your strategy. Will
> write mode be implemented later? Should I port the M5 tableViewer binding to
> M6? What will be provided in final release in june? What would be the more
> stable way to implement a workaround?
There are two old features we have not had the bandwidth to carry forward at this point:
1) Read-write mode, and
2) Tree support
Getting this support back in is a matter of the laws of software physics: someone has to write it. Both Boris and I are swamped at the moment with enough other priorities that adding (back) major new features is out of the question. But if someone else had the time and inclination, we would be happy to work with them to help them understand the code and to help them know what kind of patch would be needed.
Realized I didn't answer some specific questions you asked: > Should I port the M5 tableViewer binding to M6? We'd love to have someone port that (and contribute it back if you can do that). > What will be provided in final release in June? Right now unless the team finds a bunch of time, things will probably be pretty much as they are. There are a handful of significant bugs in what we have that still need fixing so that the API can be as stable as a provisional API can be. For example, the business rule validator story is broken right now. There are comments in the code about what needs fixed, and we'll fix that before June. Stuff like that. > What would be the more stable way to implement a workaround? That depends largely on your application. If you need JFace's sorters and filters, then the JFace editing needs to be added back to make you happy. If you don't care about sorting and filtering in the UI control itself, but what you really want is in-place editing, then you probably want to write bindings for the new CompositeTable control that's in the examples plug-in. It can do really smooth in-place editing and doesn't have the click-to-edit, enter-to-save modal issues that editors based on the native table controls have. There's an example program that uses CompositeTable in the examples plug-in so you can see how it works. Plus the control itself has some pretty extensive JavaDoc. If what you really need is just a way to edit data that you're displaying in the table, then you can do what we're doing right now at my client: bind a bunch of Text objects to the TableViewer's current selection and let the user edit the data there. This works well right now and is well-supported. > Thanks for your reply. HTH! Is the development still active? We would like to know the state of the development. How stable is the implementation in the 3.2 release and can we use it in a production enviroment? (In reply to comment #62) > Is the development still active? We would like to know the state of the > development. How stable is the implementation in the 3.2 release and can we use > it in a production enviroment? The 3.2 implementation does not have any public API and is subject to change. This is because at the time of the API freeze for 3.2, we did not have sufficient feedback to be confident about the API. In the meantime, we have received a lot of feedback. Based on this feedback, we are currently discussing some changes (see e.g. bug 147364, bug 147563) and are targeting 3.3 M3 as the milestone for making the API public. *** This bug has been marked as a duplicate of 154132 *** I just realized that the cc list of this bug is not copied over to the new bug. If you are still interested in updates, please cc yourself on bug 154132. Thanks! |