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 -~----------~----~----~----~------~----~------~--~---
