[gwt-contrib] Re: RR: updates and design changes to incubator validation
Hey Emily, Is there a use case when a ValidatorController will hold different types of Subjects and Validators or can I assume that ValidatorController is generic and the generic type will be the same in Validators and Subjects? Regards, Arthur Kalmenson On Oct 6, 12:20 pm, "Emily Crutcher" <[EMAIL PROTECTED]> wrote: > > va 1.5 features that are now available > > > > This is pretty straight forward. I would use typed lists in > > AbstractValidationController, make Subject a generic interface (for > > the value returned), and other minor changes. > > Yes. > > > > > Use interfaces instead of abstract classes > > > > A lot of the main validation classes are abstract classes. Some > > examples are ErrorHandler, AbstractValidationController and Validator. > > This creates a lot of problems for unit testing these classes because > > you can't really mock them out, you have to instantiate them, etc. > > Therefore, I think it's better to make these classes interfaces and > > make an abstract concrete implementation that includes the current > > code. > > To me, this depends upon how well you can factor them into characteristic > interfaces. What we want to avoid is an interface with a "bundle of > functionality" where we locked out of adding more features. > > Some of the system might be able to be be mapped into the event handlers > framework or something similar (i.e. a set of validation events consumed by > validation handlers) this pattern gives the the advantages of interfaces, > but can still be enhanced over time. > > > > > Write test cases > > > > The validation library is currently missing unit tests, I'd like to > > add extensive tests. I wanted to use EasyMock (http:// > >www.easymock.org/) for testing some of the stuff that doesn't involve > > GWT.create() calls. EasyMock is under the MIT license, is it > > acceptable to use and include? > > Let me check with legal on this one. GWT code certainly runs with easy > mock, however I don't know if we can bundle it with the gwt-incubator code. > > > Remove static methods > > > > There are a number of static methods scattered around in classes like > > the DefaultTextBoxSubject, RegExValidator and ValidatorController. > > Static methods really make testing hard, and global states are in > > general bad. Is there a specific reason for these static methods? > > This is completely true of server side code, and therefore as validation is > a shared system, we would definitely want to go over it with a fine-toothed > comb. > > GWT Client side web applications, in general, are less subject to this > rule, because > > 1. They are, by nature, single threaded > 2. They are, by nature, single user > 3. They run on JavaScript, so are,by nature, slow > 4. They need to include the fewest lines of code possible, which means we > must be very careful that the compiler can trace through when code is > actually needed, in other words a lot of the injection-dependency systems > which are perfect for server code end up creating really bad GWT apps. > > > > > Annotation based validation > > > > What do you think about annotation based validation? It could look > > something like this: > > > @NotEmptyValidator > > TextBox firstName = new TextBox(); > > > @NumberRangeValidator(low = 18, high = 100) > > TextBox age = new TextBox(); > > > I like the general principle, the devil, of course, will be in the details! > > Let me know what you think. Thank you. > > > Regards, > > Arthur Kalmenson > > -- > "There are only 10 types of people in the world: Those who understand > binary, and those who don't" --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: updates and design changes to incubator validation
> To me, this depends upon how well you can factor them into characteristic
> interfaces. What we want to avoid is an interface with a "bundle of
> functionality" where we locked out of adding more features.
>
> Some of the system might be able to be be mapped into the event handlers
> framework or something similar (i.e. a set of validation events consumed by
> validation handlers) this pattern gives the the advantages of interfaces,
> but can still be enhanced over time.
I was thinking of just copying and pasting the methods the current
abstract classes have to make a new interface. For example, Validator
will look like this:
public interface Validator {
public void checkValid(Subject subject);
public void checkValid(Subject element, ErrorHandler handler);
}
and the abstract concrete implementation would be:
public abstract class AbstractValidator implements Validator {
public final void checkValid(Subject subject) {
checkValid(subject, ValidatorController.getDefaultErrorHandler());
}
}
Putting this into the event handler framework sounds like an
interesting idea. I'm not familiar with event handlers yet, but I'll
take a look.
> This is completely true of server side code, and therefore as validation is
> a shared system, we would definitely want to go over it with a fine-toothed
> comb.
>
> GWT Client side web applications, in general, are less subject to this
> rule, because
>
>1. They are, by nature, single threaded
>2. They are, by nature, single user
>3. They run on JavaScript, so are,by nature, slow
>4. They need to include the fewest lines of code possible, which means we
>must be very careful that the compiler can trace through when code is
>actually needed, in other words a lot of the injection-dependency systems
>which are perfect for server code end up creating really bad GWT apps.
Hmm, that makes sense. It's still kind of nasty from a testing
perspective. Furthermore, since you touched on dependency injection,
perhaps a good way to wire these classes together would be to use
Google GIN (http://code.google.com/p/google-gin/). It's fairly new,
but it looks very promising.
I'll add an issue about the update to Java 1.5 and I'll start
implementing that portion.
Regards,
Arthur Kalmenson
On Oct 6, 12:20 pm, "Emily Crutcher" <[EMAIL PROTECTED]> wrote:
> > va 1.5 features that are now available
> >
> > This is pretty straight forward. I would use typed lists in
> > AbstractValidationController, make Subject a generic interface (for
> > the value returned), and other minor changes.
>
> Yes.
>
>
>
> > Use interfaces instead of abstract classes
> >
> > A lot of the main validation classes are abstract classes. Some
> > examples are ErrorHandler, AbstractValidationController and Validator.
> > This creates a lot of problems for unit testing these classes because
> > you can't really mock them out, you have to instantiate them, etc.
> > Therefore, I think it's better to make these classes interfaces and
> > make an abstract concrete implementation that includes the current
> > code.
>
> To me, this depends upon how well you can factor them into characteristic
> interfaces. What we want to avoid is an interface with a "bundle of
> functionality" where we locked out of adding more features.
>
> Some of the system might be able to be be mapped into the event handlers
> framework or something similar (i.e. a set of validation events consumed by
> validation handlers) this pattern gives the the advantages of interfaces,
> but can still be enhanced over time.
>
>
>
> > Write test cases
> >
> > The validation library is currently missing unit tests, I'd like to
> > add extensive tests. I wanted to use EasyMock (http://
> >www.easymock.org/) for testing some of the stuff that doesn't involve
> > GWT.create() calls. EasyMock is under the MIT license, is it
> > acceptable to use and include?
>
> Let me check with legal on this one. GWT code certainly runs with easy
> mock, however I don't know if we can bundle it with the gwt-incubator code.
>
> > Remove static methods
> >
> > There are a number of static methods scattered around in classes like
> > the DefaultTextBoxSubject, RegExValidator and ValidatorController.
> > Static methods really make testing hard, and global states are in
> > general bad. Is there a specific reason for these static methods?
>
> This is completely true of server side code, and therefore as validation is
> a shared system, we would definitely want to go over it with a fine-toothed
> comb.
>
> GWT Client side web applications, in general, are less subject to this
> rule, because
>
> 1. They are, by nature, single threaded
> 2. They are, by nature, single user
> 3. They run on JavaScript, so are,by nature, slow
> 4. They need to include the fewest lines of code possible, which means we
> must be very careful that the compiler can trace through when code is
> actually needed, in
[gwt-contrib] Re: RR: updates and design changes to incubator validation
> > va 1.5 features that are now available > > This is pretty straight forward. I would use typed lists in > AbstractValidationController, make Subject a generic interface (for > the value returned), and other minor changes. > Yes. > > Use interfaces instead of abstract classes > > A lot of the main validation classes are abstract classes. Some > examples are ErrorHandler, AbstractValidationController and Validator. > This creates a lot of problems for unit testing these classes because > you can't really mock them out, you have to instantiate them, etc. > Therefore, I think it's better to make these classes interfaces and > make an abstract concrete implementation that includes the current > code. To me, this depends upon how well you can factor them into characteristic interfaces. What we want to avoid is an interface with a "bundle of functionality" where we locked out of adding more features. Some of the system might be able to be be mapped into the event handlers framework or something similar (i.e. a set of validation events consumed by validation handlers) this pattern gives the the advantages of interfaces, but can still be enhanced over time. > > Write test cases > > The validation library is currently missing unit tests, I'd like to > add extensive tests. I wanted to use EasyMock (http:// > www.easymock.org/) for testing some of the stuff that doesn't involve > GWT.create() calls. EasyMock is under the MIT license, is it > acceptable to use and include? > Let me check with legal on this one. GWT code certainly runs with easy mock, however I don't know if we can bundle it with the gwt-incubator code. > Remove static methods > > There are a number of static methods scattered around in classes like > the DefaultTextBoxSubject, RegExValidator and ValidatorController. > Static methods really make testing hard, and global states are in > general bad. Is there a specific reason for these static methods? > This is completely true of server side code, and therefore as validation is a shared system, we would definitely want to go over it with a fine-toothed comb. GWT Client side web applications, in general, are less subject to this rule, because 1. They are, by nature, single threaded 2. They are, by nature, single user 3. They run on JavaScript, so are,by nature, slow 4. They need to include the fewest lines of code possible, which means we must be very careful that the compiler can trace through when code is actually needed, in other words a lot of the injection-dependency systems which are perfect for server code end up creating really bad GWT apps. > Annotation based validation > > What do you think about annotation based validation? It could look > something like this: > > @NotEmptyValidator > TextBox firstName = new TextBox(); > > @NumberRangeValidator(low = 18, high = 100) > TextBox age = new TextBox(); > > I like the general principle, the devil, of course, will be in the details! > Let me know what you think. Thank you. > > Regards, > Arthur Kalmenson > > > -- "There are only 10 types of people in the world: Those who understand binary, and those who don't" --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
