gwt-validation 2.0 (halcyon)
23 views
Skip to first unread message
chris.r
May 6, 2011, 11:18:28 PM5/6/11
to gwt-validation
I know I posted that javax.validation was available in the 2.4 gwt
branch but I have been thinking a lot about reflection, code
generation, and gwt-validation lately.
I believe it is possible to create a fully generated, almost fully
compliant, fluent, and easy to use implementation of the final JSR-303
with the tools provided by GWT.
The original gwt-validation project was based on the draft of the
JSR-303 validation and suffered very much from fundamental
architecture flaws. This re-write (which you can see forming up in
the gwt-validation-2.0_dev branch of SVN) aims to address these
flaws. I am giving this branch the name "Halcyon" because it does
point to a significant improvement in all areas of the validation
framework. Happy days are here...
The first major flaw that Halcyon address is that each validator class
was generated separately even though it used the same validation
algorithm as the others. This made it almost impossible to debug
different validators. Also, no metadata was available at runtime and
no reflection-like functions were available to work at the bean
property level. Halcyon takes a different approach. The *metadata*
for each constrained class is generated as well as a simple reflector
that allows some runtime interactivity with the class. The
IReflectorFactory interface, super-src overlay, and the
ReflectorFactory combined with code generation all make this
possible. I have just finished the code for this and it works a
treat. It needs more testing but I'm happy with the way it works out.
The second major flaw that was present in the 1.0 series is that the
generated classes were generated in line with the source file that
caused the generation. I have since been using FreeMarker and code
templates. This works so much better that I can't even begin to
describe the change. Everything is much clearer and easier to debug.
I've also found out that GWT can expose a simple PrintWriter that
writes files to the context instead of relying on the SourceWriter
which is apparently doing some other things behind the scenes.
Halcyon doesn't need these things because it generates the full class
with all of the details.
Some other minor flaws that are being addressed as a side effect:
* Interface validation is fully supported because of the way that
metadata generation works.
* The BeanInfo and Introspector classes are used for bean and
property names so that problems with property names (See: issue 005)
should no longer be the case.
* The way that RegEx works will be greatly simplified and we
should be able to handle even complex regex without having to do weird
character escapes
Many more things will be addressed simply because the architecture on
this solution is much better. Over the two weeks I've been working on
this I've cranked out about 1.8KLOCS. Just wanted to share.
Let me know if you have any questions, comments, concerns or requests.
In the spirit of open source,
Chris
branch but I have been thinking a lot about reflection, code
generation, and gwt-validation lately.
I believe it is possible to create a fully generated, almost fully
compliant, fluent, and easy to use implementation of the final JSR-303
with the tools provided by GWT.
The original gwt-validation project was based on the draft of the
JSR-303 validation and suffered very much from fundamental
architecture flaws. This re-write (which you can see forming up in
the gwt-validation-2.0_dev branch of SVN) aims to address these
flaws. I am giving this branch the name "Halcyon" because it does
point to a significant improvement in all areas of the validation
framework. Happy days are here...
The first major flaw that Halcyon address is that each validator class
was generated separately even though it used the same validation
algorithm as the others. This made it almost impossible to debug
different validators. Also, no metadata was available at runtime and
no reflection-like functions were available to work at the bean
property level. Halcyon takes a different approach. The *metadata*
for each constrained class is generated as well as a simple reflector
that allows some runtime interactivity with the class. The
IReflectorFactory interface, super-src overlay, and the
ReflectorFactory combined with code generation all make this
possible. I have just finished the code for this and it works a
treat. It needs more testing but I'm happy with the way it works out.
The second major flaw that was present in the 1.0 series is that the
generated classes were generated in line with the source file that
caused the generation. I have since been using FreeMarker and code
templates. This works so much better that I can't even begin to
describe the change. Everything is much clearer and easier to debug.
I've also found out that GWT can expose a simple PrintWriter that
writes files to the context instead of relying on the SourceWriter
which is apparently doing some other things behind the scenes.
Halcyon doesn't need these things because it generates the full class
with all of the details.
Some other minor flaws that are being addressed as a side effect:
* Interface validation is fully supported because of the way that
metadata generation works.
* The BeanInfo and Introspector classes are used for bean and
property names so that problems with property names (See: issue 005)
should no longer be the case.
* The way that RegEx works will be greatly simplified and we
should be able to handle even complex regex without having to do weird
character escapes
Many more things will be addressed simply because the architecture on
this solution is much better. Over the two weeks I've been working on
this I've cranked out about 1.8KLOCS. Just wanted to share.
Let me know if you have any questions, comments, concerns or requests.
In the spirit of open source,
Chris
chris.r
May 19, 2011, 11:04:56 AM5/19/11
to gwt-validation
Updating to include current progress.
JSR-303 Supported Sections
Chapter 2: Constraint Definition
2.1: Constraint Annotation (100%)
2.2: Applying multiple constraints of the same type (100%)
2.3: Constraint composition (100%)
Chapter 5: Constraint metadata request APIs
5.1: Validator (0%)
5.2: ElementDescriptor (75%)
ConstraintFinder (33%)
5.3: BeanDescriptor (50%)
5.4: PropertyDescriptor (100%)
5.5: ConstraintDescriptor (100%)
5.6: Example [implemented as JUnit test] (0%)
This may not look like a lot, but it is the bulk of the metadata
generation and the only reason that the Element and Bean descriptors
have not been completed is because I did not read the JSR closely
enough. Things are proceeding apace.
Chris
JSR-303 Supported Sections
Chapter 2: Constraint Definition
2.1: Constraint Annotation (100%)
2.2: Applying multiple constraints of the same type (100%)
2.3: Constraint composition (100%)
Chapter 5: Constraint metadata request APIs
5.1: Validator (0%)
5.2: ElementDescriptor (75%)
ConstraintFinder (33%)
5.3: BeanDescriptor (50%)
5.4: PropertyDescriptor (100%)
5.5: ConstraintDescriptor (100%)
5.6: Example [implemented as JUnit test] (0%)
This may not look like a lot, but it is the bulk of the metadata
generation and the only reason that the Element and Bean descriptors
have not been completed is because I did not read the JSR closely
enough. Things are proceeding apace.
Chris
chris.r
May 26, 2011, 11:27:49 AM5/26/11
to gwt-validation
Updated Progress Report as of SVN r151
JSR-303 Supported Sections
Chapter 2: Constraint Definition
2.1: Constraint Annotation (100%)
2.2: Applying multiple constraints of the same type (100%)
2.3: Constraint composition (100%)
2.4: Constraint Validation Implementation (5%)
2.5: ConstraintValidatorFactory (100%)
Chapter 3: Constraint declaration and validation process
3.1: Requirements on classes to be validated [implemented with
Introspector] (100%)
3.2: Constraint declaration (100%)
3.3: Inheritance (100%)
3.4: Group and group sequence (50% - 100% group and 0% group
sequence)
3.5: Validation Routine (75% - needs testing with complex object
graphs)
3.6: Examples [implemented in JUnit] (0%)
Chapter 4: Validation APIs
4.1 Validator API (100%)
4.2 ConstraintViolation (25%)
4.3 Message Interpolation (0%)
4.4 Bootstrapping (10%)
5.2: ElementDescriptor (90%)
ConstraintFinder (100% reflective, 80% client)
5.3: BeanDescriptor (100%)
JSR-303 Supported Sections
Chapter 2: Constraint Definition
2.1: Constraint Annotation (100%)
2.2: Applying multiple constraints of the same type (100%)
2.3: Constraint composition (100%)
2.5: ConstraintValidatorFactory (100%)
Chapter 3: Constraint declaration and validation process
3.1: Requirements on classes to be validated [implemented with
Introspector] (100%)
3.2: Constraint declaration (100%)
3.3: Inheritance (100%)
3.4: Group and group sequence (50% - 100% group and 0% group
sequence)
3.5: Validation Routine (75% - needs testing with complex object
graphs)
3.6: Examples [implemented in JUnit] (0%)
Chapter 4: Validation APIs
4.1 Validator API (100%)
4.2 ConstraintViolation (25%)
4.3 Message Interpolation (0%)
4.4 Bootstrapping (10%)
Chapter 5: Constraint metadata request APIs
5.1: Validator (100%)
5.2: ElementDescriptor (90%)
ConstraintFinder (100% reflective, 80% client)
5.3: BeanDescriptor (100%)
5.4: PropertyDescriptor (100%)
5.5: ConstraintDescriptor (100%)
5.6: Example [implemented as JUnit test] (0%)
5.5: ConstraintDescriptor (100%)
5.6: Example [implemented as JUnit test] (0%)
Reply all
Reply to author
Forward
0 new messages