Community
Participate
Working Groups
I would like to use parts of the databinding framework in a servlet container where a dependency on SWT should be avoided. I think it would be worthwhile to extract the SWT specific code from the databinding framework into its own bundle.
Yes. We should try to get approval for new plug-in projects for M2. This is what I would like to propose to the PMC: org.eclipse.jface.databinding "core data binding framework" class library: J2ME Foundation 1.0 dependencies: org.eclipse.equinox.common org.eclipse.jface.databinding.ui "binding to SWT and JFace" class library: J2ME Foundation 1.0 dependencies: org.eclipse.jface.databinding org.eclipse.equinox.common org.eclipse.jface org.eclipse.jface.databinding.beans "binding to Java beans" class library: J2SE 1.4 dependencies: org.eclipse.jface.databinding org.eclipse.equinox.common My original rationale for this proposal (copied from an old e-mail): The motivation for separating the beans part is to avoid dependencies on non-foundation classes, in particular java.beans, which brings in references to java.awt. Since the SDK does not use the JavaBeans event mechanisms, this plug-in would not be used by the SDK. The motivation for separating the remaining code further, into a core part and a UI part, is that then the beans plug-in would not have indirect dependencies on SWT or JFace. Eventually, others might provide other model-side plug-ins (e.g., support for binding to EMF objects). Those plug-ins should not use any of the SWT or JFace specific parts, and the only way to enforce this is to put the SWT and JFace code into a separate plug-in. After splitting the plug-in into three, we can easily resolve bug 115887 as well.
great :)
(In reply to comment #0) > I would like to use parts of the databinding framework in a servlet container > where a dependency on SWT should be avoided. Just curious - which parts of the framework are useful in a servlet container?
Actually, I haven't got into deep coding yet. I'm still exploring some ideas. The way I'm heading right now is to somehow create/obtain an observable from the model on the server. I then want to convert the value to some serializable form that I can send across the wire using the API provided by the framework. So databinding will be used on two sides. I just have to establish a connection somehow between. But I don't think that the connection will be very active (like it would be within the same VM). I want to use JFace databinding under the hood and hide most of its capabilities on the server side. For example, it won't scale to call the server after every keystroke. Also, only some validation can already happen on the client side whereas some might be an expensive AJAX like callback.
I got sidetracked by too many 3.2.1 issues so this will have to be done for M3.
Adding the PMC members to the CC list. I am asking for approval to split the JFace data binding plug-in into three as described in comment #1.
Sounds like the right direction to me. +1.
Would it be possible to make the core plugin independent of the Eclipse runtime as well? This way JFace binding could be used for stand-alone Swing applications. I've tried this by removing all Eclipse and SWT specific stuff from the core and writing some Swing IObservables. After those modifications JFace DataBinding could easily be used in a test Swing application. Actually the only dependencies on Eclipse core right now seem to be the Assert and logging facilities. Perhaps these can be injected rather than used directly?
(In reply to comment #8) > Would it be possible to make the core plugin independent of the Eclipse > runtime as well? This way JFace binding could be used for stand-alone > Swing applications. I knew someone would try this! :) The core data binding plug-in will only depend on org.eclipse.equinox.common, which is a small jar file (about 80 K), and can be used without OSGi running. > Actually the only dependencies on Eclipse core right now seem to be the Assert > and logging facilities. Perhaps these can be injected rather than used > directly? Right now, these are dependencies on JFace and we will remove them or replace with corresponding interfaces or classes from equinox.common. Logging will be injected in a way similar to how this is solved in JFace. We will use Assert and IStatus from equinox.common, and I could see us potentially using other classes or interfaces from equinox.common in the future, such as e.g. ISafeRunnable/SafeRunner, ListenerList, IProgressMonitor, and IAdaptable.
The new projects have been created and I am waiting for them to be included in the builds.
Released - this should be in the builds from now on, or check out the to additional projects from CVS.
Given that the core libraries have nothing to do with JFace: org.eclipse.jface.databinding "core data binding framework" class library: J2ME Foundation 1.0 dependencies: org.eclipse.equinox.common Why is the plugin called 'org.eclipse.jface.databinding'? It seems counterintuitive that a plugin org.eclipse.jface.xxx has no UI dependencies. Worse, it may lead the average person to think that org.eclipse.jface.databinding has dependencies on org.eclipse.jface and thus it's not useful if writing non-UI code. org.eclipse.databinding would have been better, as would have anything else that didn't start with org.eclipse.jface...
This is a good point. Boris, can we rename our core package as suggested?
Note that it should also be done for the javabeans binding ... org.eclipse.jface.databinding.beans "binding to Java beans" class library: J2SE 1.4 dependencies: org.eclipse.jface.databinding org.eclipse.equinox.common I'd suggest that all of the bundles have the same prefix: org.eclipse.databinding org.eclipse.databinding.beans org.eclipse.databinding.jface That way, it makes it easier to add new bindings (SWT, Swing, EJB etc.) by simply adding a new suffix.
(In reply to comment #14) > org.eclipse.databinding > org.eclipse.databinding.beans > org.eclipse.databinding.jface The only problem with this: the org.eclipse.* namespace is reserved for Eclipse top-level projects. That's why we ended up with the org.eclipse.jface prefix. (Yes - JFace is not a top-level project. It got that name because it predates the notion of top-level project.) org.eclipse.core.databinding may be possible for the core plug-in, but then what would be the names of the other two plug-ins?
I'll note that this bug is marked as fixed but it appears there is still some work to be done. Should it be reopened? As for naming, core is fine for, well, the core (non-ui) stuff. Seems like org.eclipse.jface.databinding (or whatever) works then for the UI stuff. If there was someone else building some web/... integration with databindings they could use ...web.databinding...
(In reply to comment #16) > I'll note that this bug is marked as fixed but it appears there is still some > work to be done. Should it be reopened? > > As for naming, core is fine for, well, the core (non-ui) stuff. Seems like > org.eclipse.jface.databinding (or whatever) works then for the UI stuff. If > there was someone else building some web/... integration with databindings they > could use ...web.databinding... ... or ...emf.databinding This makes sense to me. +1 Reopening per Alex's comment and Jeff's suggestion.
(In reply to comment #17) > > could use ...web.databinding... > > ... or ...emf.databinding OK, so far we have: org.eclipse.core.databinding (core part) org.eclipse.jface.databinding (UI part) How does the beans support fit in? org.eclipse.core.beans.databinding? org.eclipse.core.databinding.beans? org.eclipse.something.else.beans.databinding?
personaly, org.eclipse.core.databinding.beans
(In reply to comment #19) > personaly, org.eclipse.core.databinding.beans > +1
I think the databinding stuff should have the same prefix. +1 for org.eclipse.core.databinding.jface -1 for org.eclipse.jface.databinding The org.eclipse.(databinding|jface) is an adapter for the databinding libraries to connect to JFace, not an adapter for JFace to talk to the databinding libraries. Therefore, I believe the prefix should be o.e.core.databinding.jface. It also makes it a heck of a lot easier when you add new features/bindings in the future: org.eclipse.core.databinding.beans org.eclipse.core.databinding.swing org.eclipse.core.databinding.telepathy etc.
I actually prefer org.eclipse.jface.databinding. The reason being that if I'm looking for databinding support for a project I'm going to look for support in that project as I assume that the project owns it's databinding support. So when looking for jface databinding support I'll look for org.eclipse.jface.databinding, for GEF support I'll look for org.eclipse.gef.databinding, etc.
(In reply to comment #21) > I think the databinding stuff should have the same prefix. > > +1 for org.eclipse.core.databinding.jface > -1 for org.eclipse.jface.databinding > > ... > > org.eclipse.core.databinding.beans > org.eclipse.core.databinding.swing > org.eclipse.core.databinding.telepathy I tend to disagree, because plug-in names also denote ownership. If BIRT decided to write a plug-in for binding to BIRT charts, it should be called org.eclipse.birt.databinding, not org.eclipse.core.databinding.birt. Another example would be EMF - should they decide to make EMF objects bindable, the resulting plug-in should be called org.eclipse.emf.databinding. It follows (at least for me) that org.eclipse.jface.databinding is a good name for the plug-in that offers support for binding to JFace things. For me, the odd one of the three proposed plug-in names is org.eclipse.core.databinding.beans. However, I don't have very strong feelings about this, so if you all agree that the common prefix should be org.eclipse.core.databinding then that's fine with me. Can we try to reach consensus on this soon? Note that once we have a proposal that we like, it still has to be brought forward to and approved by the PMC.
To make my vote official, my +1 goes to: * org.eclipse.core.databinding * org.eclipse.core.databinding.beans * org.eclipse.jface.databinding The way I see it is that if there's a project then the databinding implementation belongs to it. If there isn't a project then we look for an appropriate owner and assign the support to that owner (e.g. because bean support is core to java it belongs in the org.eclipse.core.databinding namespace).
(In reply to comment #24) > To make my vote official, my +1 goes to: > > * org.eclipse.core.databinding > * org.eclipse.core.databinding.beans > * org.eclipse.jface.databinding > > The way I see it is that if there's a project then the databinding > implementation belongs to it. If there isn't a project then we look for an > appropriate owner and assign the support to that owner (e.g. because bean > support is core to java it belongs in the org.eclipse.core.databinding > namespace). I'll make my comments succinct: +1 :-)
+1 me too
+1
The plug-ins are now renamed as discussed.
Verified that we have three different plug-ins in I20061213-0800, only one of which depends on SWT and JFace.
