|
Replies:
7
-
Last Post:
Mar 28, 2008 5:38 AM
by: danielrohe
|
|
|
|
|
|
|
CellEditor Validation Framework
Posted:
Mar 26, 2008 8:44 PM
|
|
|
I have made an initial check in of a validation framework for CellEditors. I hope to accomplish the following goals:
1. Create highly reusable validation code.
2. Eliminate the need to create custom editors to perform validation.
3. Separate validation logic from presentation (editing) logic.
4. Provide instanteous feedback that the user has entered an invalid value (currently a simple red border).
I have created a JXTable and JXTree subclasses, enhanced to enable the use of validators. I have modified TableColumnExt to use validators (I know, Jeanette, but it was so much easier than creating a custom ColumnFactory and a subclass). The validator package contains a large collection of common validators. The centerpiece to this is the ValidatingCellEditor, which the X-subclasses use to wrap the "normal" editor. This editor runs the validator on the value whenever cell editing is stopped and prevents the editing from stopping whenever the validator fails. The validator has no effect when editing is canceled.
This validation is user-centered. No validation is done for manual editing of the the model data. Validation only occurs whenever the user attempts to edit a value with a CellEditor. This means it is possible to display and even create "invalid" values. This framework is for preventing improper user input.
I have two tests: one for the table and one for the tree. The table has a validator on the first column only and accepts values [3-5] inclusive. The tree has a validator that requires new values to be exactly 3 characters in length.
Let me know if you check it out. Feedback welcomed.
By the way, I cleaned up my incubator tonight, to hopefully make it easier for people to get code from it. I also removed all code that has migrated into SwingX.
Karl
|
|
|
|
|
|
|
Re: CellEditor Validation Framework
Posted:
Mar 27, 2008 4:02 AM
in response to: kschaefe
|
|
|
Haven't had a look at your code yet, but Validation hits one of my sore spots over the state of beansbindings which as its own very rudimentary validation. Been wondering how this (and yours?) maps to the Validation JSRs such as JSR 303 which was drafted recently: http://www.theserverside.com/news/thread.tss?thread_id=48810
Unfortunately most of our validation is done server-side which means results are always a SwingWorker away - which makes life so much more difficult (esp for veto-like behaviors).
|
|
|
|
|
|
|
|
|
Re: CellEditor Validation Framework
Posted:
Mar 27, 2008 6:05 AM
in response to: osbald
|
|
|
> Been wondering how this (and yours?) maps
> to the Validation JSRs such as JSR 303 which was
> drafted recently:
> http://www.theserverside.com/news/thread.tss?thread_id
> =48810
Don't know for sure.
I think that the validation idea is great, but what's it going to do for Swing? Nothing. They suggest that the API is usable in all programming models, and that may be true, but Swing programmers need special components to take advantage of the new APIs. They are not producing these components. Even if my bean has validation code, if my CellEditior does not respect that code the user could enter bogus data. What state am I in? How do I recover? How do I inform the user?
It doesn't matter what APIs 303 develops, we'll need Swing "adapters" to utilize them. Consider the CellEditor. It is a strange beast (to say the least). It maintains it's own value, which is only synchronized with the model after stopCellEditing has been successfully executed. That means that the user has already entered a value and stopped editing, when the value is placed into the bean. Without some Swing components that are knowledgable of the APIs, you get into a state where the edtior is closed, but the edit is rejected. We should prevent such a case, and I do. This framework can be used with the metadata APIs in 303 or without.
As soon as 303 produces, real code, I'll be happy to include a 303-based bean validator in this editor framework.
Karl
|
|
|
|
|
|
|
|
|
Re: CellEditor Validation Framework
Posted:
Mar 27, 2008 6:09 AM
in response to: kschaefe
|
|
|
Karl,
have to admit that I didn't yet look at your code. But ... I'm very
weary with yet another validation mechanism. Starting at zero when we
have JGoodies Validation and beansbinding validation and the jsr feels
basically wrong.
Need to look soon 
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: CellEditor Validation Framework
Posted:
Mar 27, 2008 6:30 AM
in response to: Kleopatra
|
|
|
Kleopatra schrieb:
> have to admit that I didn't yet look at your code. But ... I'm very
> weary with yet another validation mechanism. Starting at zero when we
> have JGoodies Validation and beansbinding validation and the jsr feels
> basically wrong.
>
forgot to mention core swing low-level validation: the InputVerifier 
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: CellEditor Validation Framework
Posted:
Mar 27, 2008 6:47 AM
in response to: Kleopatra
|
|
|
Jeanette,
> But ... I'm very
> weary with yet another validation mechanism. Starting
> at zero when we
> have JGoodies Validation and beansbinding validation
JGoodies validation is great. Nice feedback, etc. I've only used the JGoodies demo, so I don't know, but I've never found anything that worked correctly with CellEditors. Most of the editing that my users do is table-based. CellEdtiors always seem the odd-man out. If I need validation for them, I have to create a new editor and use a yucky InputVerifier or some other validation mechanism. I want to avoid custom edtiors altogether.
Honestly, I don't see this as a replacement for any other validation framework. More like an easy drop-in for validation code into one of the dark corners of Swing.
> the jsr feels basically wrong.
Because it's too EE-centric. But I like the idea.
Karl
|
|
|
|
|
|
|
|
|
Re: CellEditor Validation Framework
Posted:
Mar 28, 2008 5:38 AM
in response to: kschaefe
|
|
|
I've used JGoodies Validation extensively on domain objects with feedback in any type of user interface component (tables, lists) which where bound to lists using JGoodies Binding . Especially for these components I had to enhance the ValidationMessage and ValidationComponentUtils. The enhancement brought me to the point where feedback can be on a complete row or a single cell based on the existing validation message. The developer was still be able to develop like he used plain JGoodies Validation.
This reminds me to publish the enhancements.
|
|
|
|
|
|
|
|
|
Re: CellEditor Validation Framework
Posted:
Mar 27, 2008 7:00 AM
in response to: kschaefe
|
|
|
What I meant being able to take say the JSR 303 validation definitions from the annotations and using them to drive the adapters. Obviously this JSR isn't targeted at the Swing UI (don't know about the other validation proposals).
What interests me is more where and how the validations are defined - thinking client & server. Given a decent bindings framework I'd hope to be binding directly to domain objects that'd carry these validation annotations. Don't want to continuously have to code separate validation checks on both client and server ends (or other layers). Ideally they should be sharing their definition of validity (obviously theres always going to be other levels like unique keys in a database that the client could never check).
Like Jeanette I don't like seeing lots of APIs trying to do the same thing but in entirely incompatible ways. This is also why I think shelving beansbindings is dangerous while they'res important decisions being made on related JSRs like properties and validation.
Anyway just alerting everybody to its existence and apparent progress.
|
|
|
|
|
java.net RSS
