Okay, I can't emphasize how important this is, because GWT is not perfect, and it needs fixing from time to time. I just wasted two days on just such a problem.
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)? I can give you the example of what I just ran into. I have a page with a date range for a search (for which I use two date boxes), among other criteria. Whenever any criteria changes I want to highlight the search button, to show that it needs to be pressed (or, alternately, I could fire the search automatically). This works fine when the user uses the GUI DatePicker, because it fires a ValueChangedEvent. But keystrokes do not.. they trigger the (private) updateDateFromTextBox() method, which in turn triggers the (private) setValue(Date oldDate, Date date, boolean fireEvents) method. Because these are private, I can't override them. I also attempted to simply list for the fairly basic DateChangeEvent class, and was blocked because that entire class is private. [Listen for key events? Nope, sorry, the internal box field is private, so we can't attach a listener to that, and DateBox doesn't expose it's own listener for access.] So... my only resolution was to do the worst possible thing (breaking-code-wise) and to copy the GWT DateBox and DateChangeEvent classes, creating my own versions where I change the private methods to protected, and am then able to override them as necessary (in this case, overriding updateDateFromTextBox() to first call super.updateDateFromTextBox(), and then to trigger an onValueChange event/method. This sort of subterfuge is infuriating to have to wind one's way into. And if you make any fixes or changes to those classes, the code cannot take advantage of them... and the fact that this has even been done is buried in the javadoc for those classes (although at least I added it in bold caps). I've also run into other cases where even this brute-force-and-dreaded solution to a simple problem just is not possible, where key components in the class ancestry are private and the complex evolution from BasicThingy to UsefulThingy is too convoluted to overcome. The easy answer? Make the updateDateFromTextBox() method trigger a value changed event. But longer term? Recognize that Google makes mistakes from time to time, and use protected methods so that competent programmers can overcome your mistakes without juggling hand-grenades. On Friday, February 17, 2012 1:06:02 PM UTC-5, Tony Edgin wrote: > > I can understand your frustration, but moving most implementation > details of library to its interface would put a chokehold on the > library's development. Most of the implementation would become locked > down for fear of breaking client code. > > I know its painful, but if you need access to a field or a private > method of a class, first reconsider your design. You are attempting > to use the class in a way the designer of the class didn't intend. > After reconsidering your design. If you still think the class's > interface needs to be extended, put in a change request. Then the > designer of the class can see if it makes sense to have in the > internal functionality exposed through the class's interface. > > On Thu, Feb 16, 2012 at 07:28, Bob Lacatena <[email protected]<javascript:>> > wrote: > > I invariably find that GWT doesn't do exactly what I need. Too often, > > however, I'm frustrated in my efforts to extend a class because too > > many elements or methods are private (rather than protected) and such > > private fields are not even exposed by getters and setters. > > > > Please go through all of your code and change "private" to > > "protected". In the rare case where you really don't want someone > > touching something (e.g. deprecated methods) that's fine, but think > > ten times about having a private field without a getter/setter, or a > > private method of any sort. Such a situation should be very, very > > rare in a toolkit that's meant to be extensible, and is obviously > > limited in functionality and absolutely will require that the > > programmer roll up his sleeves. > > > > -- > > You received this message because you are subscribed to the Google > Groups "Google Web Toolkit" group. > > To post to this group, send email to > > [email protected]<javascript:> > . > > To unsubscribe from this group, send email to > [email protected] <javascript:>. > > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > > > > -- > Tony Edgin > Software Architecture and Design Leader > LBT Observatory > 933 N. Cherry Ave., Tucson AZ 85721-0065 > p:520-626-8951, c:520-419-8821, f:520-626-9333 > > -- 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 [email protected]. To post to this group, send email to [email protected]. 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.
