Community
Participate
Working Groups
Support for binding, converting and validating java.sql.Timestamp values.
Created attachment 74587 [details] Adds support for converting and validating java.sql.Timestamp
Boris, from what I can tell CDC 1.0[1] doesn't include java.sql.*. We'd either need to: 1. change the minimum requirements of org.eclipse.core.databinding 2. include it in another project 3. not include it at all My guess is 2 or 3 is the most realistic of the options. [1] http://java.sun.com/products/cdc/reference/cdc_packages.pdf
I think it is important for users who are developing J2SE and J2EE applications for Data Binding to support as many types as possible for binding, certainly all commonly used Java types. So although yes it is another package, I ask that we start one for these classes. No doubt there will be many more types to support. Can I also ask that this package be Java 5 so that we can add items like Enum support into this package?
(In reply to comment #3) > I think it is important for users who are developing J2SE and J2EE applications > for Data Binding to support as many types as possible for binding, certainly > all commonly used Java types. You have to provide scope to that statement or this quickly gets out of hand. The current scope of the core project is to support the CDC. This is done this way so that it can be used on the majority of devices and configurations out there. We have to be careful with trying to put everything in the core as this can limit who can use it and cause performance issues. If I was to apply your statement even more broadly we'd have to support Java 6 and Java 7 data types out of the box which would limit our consumer base significantly. I think we can all agree this is not something that we want and we need to think in context of the scope that we define for the project. In saying that I'm not sure how many devices out there only support the CDC. But the CDC is the basis of Java ME so there's got to be a few. The API has been designed so that the consumer doesn't have to rely only upon the core offering. You can add support for your own types and those that are not available in the CDC. The library is extensable and was made this way for this very reason. > Can I also ask that this package be Java 5 so that we can add items like Enum > support into this package? Because of the scope of the core project this isn't possible but there's nothing stopping anyone from doing so in their own code or starting a separate project that provides these types. My understanding is that we won't be moving to Java 5 without a compelling reason to do so. I agree it would be nice but like in all design we have tradeoffs and currently we've decided to not support Java 5 language features in the core project. There's always a possibility of us staring a new project that provides this support but I think that we're still wanting the core to use the CDC and 1.4 language features. But I think that decision is ultimately up to Boris.
(In reply to comment #4) > Because of the scope of the core project this isn't possible but there's > nothing stopping anyone from doing so in their own code or starting a separate > project that provides these types. My understanding is that we won't be moving > to Java 5 without a compelling reason to do so. I agree it would be nice but > like in all design we have tradeoffs and currently we've decided to not support > Java 5 language features in the core project. > > There's always a possibility of us staring a new project that provides this > support but I think that we're still wanting the core to use the CDC and 1.4 > language features. But I think that decision is ultimately up to Boris. > I find myself in a dilemma with Data Binding. Yes, it's a good, clean base API. A pleasure to use. I also understand the restrictions of being in eclipse core; CDC compliance.. legacy JRE support.. etc. However I still find that I want Data Binding to have more features and type support needed in the real world, 'out of the box'. I also anticipate that many other users will feel the same. I develop many more rich J2EE 'database apps' than I do CDC-level / Mobile apps, and I need the rich types and integration with other common APIs. I think support for Data Binding would be greater if it comes as a complete tool for these sort of applications rather than something extensible with 75% of what is needed. I have had to extend data binding quite a bit for just one app, with new types and features, and unfortunately many functional enhancements for binding require extending the core in some way to allow support to be inserted cleanly without branching. We also need more documentation to introduce new people. I want to contribute this 'completeness' to the Data Binding project itself, in the spirit of open source. Inside the data binding community. I'm not one to branch or open a separate project with separate facilities, then try and keep a branch in sync with data binding HEAD over time. This brings me back to the dilemma. I feel the restrictions of extending data binding as a product in it's current context...
(In reply to comment #5) > However I still find that I want Data Binding to have more features and type > support needed in the real world, 'out of the box'. > I also anticipate that many other users will feel the same. > I develop many more rich J2EE 'database apps' than I do CDC-level / Mobile > apps, and I need the rich types and integration with other common APIs. The API is extensible. You're not locked into one implementation. In comment 4 I stated that we might be able to provide support for more 'out of the box' with another project. Why wouldn't that satisfy your needs? We can't satisfy everyone's needs with one implementation. Occasionally someone is going to want something more or a little different. We provide that ability by allowing the consumer to add what they need via the existing API. We're open to adding to the library but we have to ensure that we don't preclude an entire group of consumers from using the library to make things a little bit better for others. > I'm not one to > branch or open a separate project with separate facilities, then try and keep a > branch in sync with data binding HEAD over time. You don't have to branch the code in order to add functionality for the use cases that you have stated. This is why we have created extensible APIs, so that consumer can be in control when necessary. You could create a basic factory, a new type, or use dependency injection in order to accomplish your needs. I want to be very clear. We can add support for new types and I'm not against discussing creating a new project that provides this support. Boris, what do you think? Also in the pre 3.3M5 (I think that's right) we had monolithic factories that everyone contributed to. It had performance issues and was difficult to maintain and debug. I personally would like to stay away from this as an author and a consumer of the library.
Brad, Please could you clarify your words "another project" for me. I don't know what you mean. Another package? A separate project altogether? What form would this take? Thanks.
Currently UpdateStrategy resides in the org.eclipse.core.databinding (what you check out of CVS). Another project could be org.eclipse.core.databinding.java5 or something similar. It would be a new endstate (e.g. jar) thus a new dependency for those who need it.
(In reply to comment #8) > Another project could be org.eclipse.core.databinding.java5 > or something similar. It would be a new endstate (e.g. jar) thus a new > dependency for those who need it. Sounds good. (Not sure what to call it, though, the emphasis is not on java 5) I imagine it will end up containing various additional type support and binding tools. A list of the kinds of code I have here that is a candidate for discussing and possible inclusion in such a package is: - java.sql.Timestamp support - Enum support - ConstraintValidator (several common business data constraints) - ObservableGroup - ValidationDependency concept (this and ObservableGroup provide me with relational validation between fields) - ValueToDescriptionConverter - DescriptionToValueConverter - StaticValue - Partial Validation equivalent functionality - Nebula CDateTime support - Nebula FormattedText support Quite a variety of items. How do we go about a new project?
(In reply to comment #9) > How do we go about a new project? > I think I need to discuss with Boris first to make sure this is what we want to do. Adding Dave to the CC in case he has an opinion.
(In reply to comment #9) > Sounds good. (Not sure what to call it, though, the emphasis is not on java 5) Actually yes it is, or at least that's my initial feeling. > I imagine it will end up containing various additional type support and binding > tools. If you have additions please log bugs for them. If we went the route of a new project it would have a well defined scope like the other projects. It wouldn't contain Nebula as Nebula needs it's own project to not force this dependency upon all consumers.
(brain dump, don't hold me to it...) I've been thinking a bit today about our strategy for converter maintenance. We have a bit of an issue with defaulting converters and also allowing consumers to configure defaulted converters. One issue is that if the consumer wants to add a default they will have to do so in extensions of UpdateValueStrategy and UpdateListStrategy and eventually any others that we create. This is less than ideal. Here are a couple of thoughts on the issue... 1. Default converters supplied in UpdateStrategy should not need configuration if at all possible. The problem with exposing configuration is that we could end up creating a lot of API and over time this could make the class quite rigid. 2. Allow for the consumer to add factories to an instance of UpdateStrategy. This should not be static as this class is not an "application level" strategy. If we were to make converter factories static it would affect unexpecting consumers. Consumers could make the converters in their factories static if they so desired for optimization purposes. 3. Move the NumberFormat support into a factory mentioned in item 2. By default we would use this factory but we'd allow the consumer to set a new NumberFormat factory to customize the defaults. I'm not sure of the API that we'd employ (i.e. if we expose a way to refer to an actual factory or just use a stack like approach and the latest that supports converting from/to the requested type is chosen). This is related to bug 198296. What ever it is it would need to be fast. The support could be like IAdapterFactory which requires consumers to declare the types they support. If externalized we'd be able to optimize the choosing of a converter over time. This approach would still assume that the consumer would need their own factory for the creation of strategies (or dependency injection, etc.) but we'd be allowing them to add support per instance via API rather than extension of every type. This would then make the Java 5 support straight forward to add and wouldn't impact consumers who aren't running a Java 5 JRE. But this would still need to be in a separate project because of the execution environment restrictions on org.eclipse.core.databinding.
I think it is a good idea to create a new plug-in (project) for binding to types that are not available in CDC Foundation 1.0. I would try to avoid referencing a specific version (like Java 5) because that quickly leads to an unbound number of new plug-ins, one for each language version. My suggestion would be to use a generic name (perhaps org.eclipse.core.databinding.extended, or .optional?) and target Java 5 for now based on the fact that Java 5 is of pretty widespread use. The new plug-in could re-export all of org.eclipse.core.databinding so that we can move API into the core plug-in over time without breaking clients. The new plug-in could provide a subclass of DataBindingContext that adds converters etc. for the additional types. IMO, code for binding to Nebula widgets (or anything else outside of the Java class libraries) would be out of scope and should be developed outside of the core data binding framework.
(In reply to comment #13) > My suggestion would be to use a generic name (perhaps > org.eclipse.core.databinding.extended, or .optional?) +1 for org.eclipse.core.databinding.extended. It seems to convey a little more as to what it is rather than if it is required. > The new plug-in could > provide a subclass of DataBindingContext that adds converters etc. for the > additional types. That's one I didn't think about. That would fix the issue of having to extend every type of strategy to add the support. > IMO, code for binding to Nebula widgets (or anything else outside of the Java > class libraries) would be out of scope and should be developed outside of the > core data binding framework. +1
+1 for org.eclipse.core.databinding.extended. +1 for Java 5 target. -1 for Nebula widgets should be developed outside of data binding framework. My point of view here is that users need to develop applications that use most datatypes available in databases and in Java. I see regular requests for "Date/Time support" and similar. Support for binding SWT controls are needed too to allow users to view and edit these datatypes. I found the SWT Date/Time/Calendar control to be inadequate and difficult to bind, so I have switched to Nebula's combined DateTime control. Similarly I know I will need FormattedText for zip code, phone number fields. etc. I want to help the framework be more ready "out of the box" for the kind of applications I and other users develop. This means supporting a suite of all common datatypes found in databases, and support for binding them to appropriate SWT controls with which to display them (including new and leading edge controls if necessary, which I have found is so). I would like to include support for further SWT controls found within the eclipse project, i.e. Nebula, where necessary, with the data binding framework (perhaps in yet another package?), where no suitable standard control exists.
Hmm.. a thought however.. Perhaps data binding support for nebula controls should reside in the Nebula project, in a separate package there. +1 for that. Maybe should speak to those guys about this.
(In reply to comment #12) (Brad's brain dump on converter maintenance) I too have been thinking about this. We need to be able to inject additional default converter support; from this new extended package, for instance. Currently this is not possible. Brad's ideas are interesting. I think this will get considered in full when we are creating the extended package and implementing support for these additional types, the issue will then come to the fore.
Meta: This bug has evolved into a strategy discussion. Perhaps it should be forked from the original request for Timestamp support? +1 for databinding.extended bundle (by whatever name) +1 for excluding Nebula support from this bundle Each of the Nebula widgets is managed as a semi-independent project with a different maintainer. I don't think it would be wise to force all of the databinding support through the funnel of one central project, since in practice each piece will evolve independently. I'm taking the strategy of adding core.databinding and jface as optional plugin dependencies for CDateTime. Client code that wants integration between these plugins can specify their own dependencies as appropriate. Those that don't will see a few harmless classes as dead weight in the CDateTime jar. The main downside is that clients don't have a one-stop-shop API like SWTObservables. I don't think that's a major problem, since client code must explicitly add each Nebula widget. They will find the data binding support when they explore each new widget API. +1 for focus on Java 5 and SQL support I envision this extended plugin as a sort of RCP-level extension of data binding support. Apps tend to consume Eclipse code in layers: SWT, JFace, Workbench/Platform UI, IDE. The current data binding APIs are aligned with the SWT and JFace layers, but more complex desktop apps could use more. I think we can safely assume that an app that depends on the full RCP is more than just a lightweight UI -- and the same goes for an extended data binding plugin.
(In reply to comment #18) > I envision this extended plugin as a sort of RCP-level extension of data > binding support. -1 The existing core project has no RCP dependencies and I don't think this should either especially since we're talking about org.eclipse.core.databinding.extended. If we were talking about creating org.eclipse.rcp.databinding then I would agree. What I'm wanting is to add more supported types but in regards to the JDK, not eclipse. If we were to put RCP depedencies in this project we'd be forcing anyone who wants support for Java 5 types to have to be an RCP app and IMO this isn't what we're shooting for.
I changed my vote from: -1 for Nebula widgets should be developed outside of data binding framework. to +1 for Nebula widgets should be developed outside of data binding framework (in Nebula itself).
(In reply to comment #19) > (In reply to comment #18) > > I envision this extended plugin as a sort of RCP-level extension of data > > binding support. > -1 for RCP. I agree with Brad. RCP constrains the client-side deliverables and is not suitable for my apps. There is no need to force consumers to depend on RCP. Data Binding is otherwise independent of all but equinox and a few other seperable eclipse plugins.
I guess I was not clear in my earlier post. I wasn't suggesting that the new plugin literally depend on RCP. (What classes would it reference, anyway?) I was just suggesting that an "extended" databinding plugin could align well with more sophisticated desktop apps. This type of app is less constrained in its environment, so it is reasonable to assume recent and full J2SE support.
(In reply to comment #22) > I guess I was not clear in my earlier post. I wasn't suggesting that the new > plugin literally depend on RCP. (What classes would it reference, anyway?) Selection service is one that comes to mind. > I > was just suggesting that an "extended" databinding plugin could align well with > more sophisticated desktop apps. If you have use cases for what this is or how it could be done can you log a separate bug as I'm still unsure as to what you mean exactly. org.eclipse.core.databinding, and whatever we create here, would have no concept of "desktop apps". The core APIs could be used in a servlet container or any other environment. My initial suggestion was to uplift the core support to the needs of more developers and Java 5 seems like a good place to start. So if there was a desktop app plugin I see it depending upon org.eclipse.core.databinding.extended but not being org.eclipse.core.databinding.extended.
I think we're talking about the same thing in different terms. I was trying to point out that there is precedent in Eclipse for layering plugins with increasing functionality and dependencies. I thought that since databinding is primarily a client-side technology (let's be honest), it could align with the layers already implemented in Eclipse. I didn't mean to imply that the databinding and RCP plugins would be conjoined in any restrictive sense, just that there is a model for what we're discussing already.
Correct me if I'm wrong but it sounds like we're in agreement. To summarize... 1. We need to create a new project, org.eclipse.core.databinding.extended. 2. This project will export org.eclipse.core.databinding API. 3. This project is to provide support for types that are not included in the CDC 1.0 and are in Java 5. 4. Everything else goes somewhere else. Boris, will we have to wait for this project to be created like we are in bug 182059?
Yes, to create a new project, we need a +1 from the PMC.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
