> I don't understand your argument that the implementation would become > "locked down" because changing methods from private to protected is opening > it up, not locking it down. Can you give an example of what you mean? How > can this possibly break existing code (barring a name conflict -- in which > case you should create new classes, created the right way, so that new > projects can use them without damaging the old projects)?
It opens the API for you, yes, but it locks down the API for the GWT team as they can not remove the protected method anymore without breaking your code that overrides that method. Its like a method on an interface. Once it exists you can not remove it anymore without breaking the code of the library users. GWT chooses to make things as private as possible to give the GWT team the freedom to change internal things without breaking any existing code. If you think something should be protected you can file an issue to request it and possibly start a discussion with the GWT team and others. In case of your DateBox you can listen for key strokes by adding key handlers to datebox.getTextBox() which holds the rendered date. But you have to test the TextBox content if its a valid date before continuing. An invalid date string would result in DateBox.getValue() to return null (if you use that value to do your search). http://google-web-toolkit.googlecode.com/svn/javadoc/latest/com/google/gwt/user/datepicker/client/DateBox.html#getTextBox() -- J. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
