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.

Bug 168262 - Integration of SimpleValidation usable across clusters
Summary: Integration of SimpleValidation usable across clusters
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Antonin Nebuzelsky
URL: http://kenai.com/projects/simplevalid...
Keywords: API, API_REVIEW
Depends on:
Blocks: 151755
  Show dependency tree
 
Reported: 2009-07-08 07:31 UTC by _ tboudreau
Modified: 2010-10-13 16:28 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ tboudreau 2009-07-08 07:31:49 UTC
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
Comment 1 Jesse Glick 2009-07-08 17:44:16 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
Comment 2 _ tboudreau 2009-07-09 01:31:14 UTC
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.
Comment 3 Jesse Glick 2009-07-09 15:32:43 UTC
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.
Comment 4 _ tboudreau 2009-07-09 19:00:26 UTC
> 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.
Comment 5 _ tboudreau 2009-08-01 20:09:21 UTC
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.
Comment 6 Jesse Glick 2009-09-21 17:07:11 UTC
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.
Comment 7 _ tboudreau 2009-09-22 19:02:43 UTC
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)
Comment 8 Jesse Glick 2009-09-22 19:52:51 UTC
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.
Comment 9 _ tboudreau 2009-09-23 02:11:14 UTC
swing.validation now in IDE cluster as of main/ changeset 54989611f293
Comment 10 Jaroslav Tulach 2010-10-13 12:32:10 UTC
What exactly am I supposed to fix in datasystems?