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