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.
Summary: | Integration of SimpleValidation usable across clusters | ||
---|---|---|---|
Product: | platform | Reporter: | _ tboudreau <tboudreau> |
Component: | -- Other -- | Assignee: | Antonin Nebuzelsky <anebuzelsky> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | hmichel, jglick, jtulach, psuchomel |
Priority: | P3 | Keywords: | API, API_REVIEW |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
URL: | http://kenai.com/projects/simplevalidation/pages/Home | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 151755 |
Description
_ tboudreau
2009-07-08 07:31:49 UTC
[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? |