This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
The SimpleValidation project is a project for, with minimal code, retrofitting user-input-validation into Swing UIs. There are other validation frameworks (notably JGoodies), but generally are designed around creating a UI from scratch and being able to create a model for the entire UI's contents. SimpleValidation is focused on Swing UIs specifically, and ease of retrofitting validation onto an existing UI. http://kenai.com/projects/simplevalidation/pages/Home The original purpose of this project was the fact that most input fields in Mobility project customizers have no validation and will accept illegal values (such as entering "garbage" as the source encoding). The framework was developed as a general means of providing per-component validation and error reporting. The Kenai project already has contributors and contributed translations. It has value for any Swing-based project and there is no reason to make it NetBeans-specific. Its immediate use is to fix the lack of validation in mobility project customizers; however, because of development priorities, its first use has been in the javacard modules. In the long-term, integrating SimpleValidation into NetBeans thoroughly can lead to the deletion of thousands of lines of code in various UIs throughout the IDE. There is an existing module that integrates it - $NBSRC/swing.validation. It also provides integration between the validation API and NetBeans wizards, and also a very convenient DialogBuilder class that eliminates most of the complexities of dealing with DialogDescriptor, while transparently handling OK button enabling via the validation framework. So we have a problem: The mobility cluster should not and cannot depend on the javacard cluster. These are completely orthagonal things - a Java ME developer should not be required to have bits related to Java Card in their IDE. In order to fix a rather large set of bugs in Mobility project customizers, Mobility needs access to the SimpleValidation library. And mobility cannot depend on the javacard cluster or we will force users to download javacard support they do not need. SimpleValidation has the potential to reduce code in a lot of other parts of NetBeans UI. So we have to do one of two things: - Create a new common cluster mobility and javacard can depend on that includes SimpleValidation, or - Make it part of the platform PROPOSAL: SimpleValidation has value for any Swing app - indeed it already has translation contributors. It should remain a standalone project. How we handle this: - Create an Hg repository for its source, that is a clone of the Kenai official version, in NetBeans hg repository collection - Build a library wrapper into platform from it - I will handle migrating changes <-> the two repositories If anybody has a better idea, I would welcome it. The requirements are: - Let both Javacard and Mobility clusters call SimpleValidation - Allow SimpleValidation to remain an independent project -Tim
[JG01] Do not put it into platform cluster, at least not yet. ide cluster for now. [JG02] Do not duplicate the source repository; there is no reason for it. Just upload the binary to the usual place and make a library wrapper for it in the usual way, referring to the project page's URL. http://wiki.netbeans.org/DevFaqExternalLibraries http://wiki.netbeans.org/ExternalBinaries
Re JG02, the reason I suggest having a clone in the NB repository tree is because it is a library that produces error messages which need to be localized. I am considering (compatibly) adding some sort of "MessageProvider" interface to it, since it is possible that some users will want to customize the error messages; that could also be a solution to the problem.
To JG02 - yes I would expect the caller to supply localized error messages. Anyway even if some localizable messages need to be in the library itself, better to add those localizations to the Kenai project directly.
> better to add those localizations to the Kenai project directly Agreed, I'm just thinking that for the case where Sun pays translators (who are not necessarily version-control savvy), it my not be a great idea to add in the complexity of having to go fetch a project off Kenai to their process.
Note that part of completing this issue will mean moving the Validation API out of the JavaCard cluster and into some cluster both Mobility and JavaCard can depend on - the only thing Java Card and Mobility have in common is that the code runs on small external devices for which there are emulators - other than that they have nothing to do with each other, and should not - there cannot be interdependencies between those to clusters. The project was originally created to solve a number of issues with Mobility projects (the fact that almost all data entry fields in the mobility project customizers will allow the user to input garbage with no checks); it just got used first in JavaCard because I was asked to drop all mobility issues and concentrate on JavaCard only for 6.7. Generally it can be used in any data entry UI to validate user input (allowing for the deletion of huge amounts of String s = jTextField1.getText().trim(); if (s.length() == 0) { setErrorMsg (...); return; } int i; try { i = Integer.parseInt (s); } catch (NumberFormatException e) { setErrorMessage (...); return; } if (i < 0) { setErrorMessage(... which occurs all over the place in all of our UI code, and could be replaced with this.validationGroup.add (jTextField1, Validators.REQUIRE_NON_EMPTY_STRING, Validators.REQUIRE_VALID_INTEGER, Validators.REQUIRE_NON_NEGATIVE_NUMBER); resulting in less buggy code and much less code overall (there are adapters that will automatically set error message and enable/disable OK/Next/Finish for both DialogDescriptors and Wizards). So, part of the question is what cluster this should live in. I need it available to both JavaCard and Mobility to fix issues for 6.8.
I already recommend ide cluster in JG01. If it is made a friend API for the time being I don't see any issues with proceeding.
Running commit-validation with swing.validation moved to the IDE cluster causes the following failure. Any idea what this is or how to fix? AFAIK it is autoload but indeed should not be enabled unless javacard.kit or something else depends on it, however the test is complaining about that fact. -- Problems found with autoloads Problems found for module org.netbeans.modules.swing.validation: [module is autoload but would not be enabled] junit.framework.AssertionFailedError: Problems found with autoloads Problems found for module org.netbeans.modules.swing.validation: [module is autoload but would not be enabled] at org.netbeans.core.validation.ValidateUpdateCenterTest.testDisabledAutoloads(ValidateUpdateCenterTest.java:166) at org.netbeans.junit.NbTestCase.access$200(NbTestCase.java:88) at org.netbeans.junit.NbTestCase$2.doSomething(NbTestCase.java:336) at org.netbeans.junit.NbTestCase$1Guard.run(NbTestCase.java:273) at org.netbeans.junit.NbTestCase.runBare(NbTestCase.java:355) at org.netbeans.junit.NbTestCase.run(NbTestCase.java:213) at org.netbeans.junit.NbModuleSuite$S.runInRuntimeContainer(NbModuleSuite.java:798) at org.netbeans.junit.NbModuleSuite$S.run(NbModuleSuite.java:573)
It would need to be added to permittedDisabledAutoloads in the test to signal that it is intentional for it to be present but disabled in some configurations, such as cluster.config=java. Really there is no "good" place for it to be because the cluster system does not work smoothly with module dependencies, so choice of cluster is often arbitrary.
swing.validation now in IDE cluster as of main/ changeset 54989611f293
What exactly am I supposed to fix in datasystems?